En este artículo
Una persona que actualiza su dirección ante una entidad no debería tener que repetir el mismo trámite ante otras tres. Sin embargo, esa fricción sigue siendo habitual cuando los sistemas públicos intercambian archivos manualmente, dependen de integraciones aisladas o conservan datos sin reglas comunes. El futuro de la interoperabilidad pública se define precisamente en ese punto: la capacidad de coordinar servicios, datos y decisiones sin trasladar la complejidad institucional a la ciudadanía.
No se trata únicamente de conectar aplicaciones. Una entidad puede tener APIs disponibles y, aun así, ofrecer una experiencia fragmentada si los datos no son confiables, los responsables no están definidos o los procesos internos continúan operando en silos. La interoperabilidad útil exige arquitectura, gobernanza y continuidad operativa.
El futuro de la interoperabilidad pública no es solo técnico
Durante años, la interoperabilidad se abordó como un problema de integración entre sistemas. Esa dimensión sigue siendo necesaria: se requieren interfaces documentadas, protocolos seguros, modelos de datos consistentes y mecanismos de monitoreo. Pero limitar la conversación a esos componentes produce conexiones frágiles, difíciles de mantener y poco alineadas con el propósito del servicio público.
La pregunta de arquitectura debe ser más amplia: ¿qué proceso necesita resolver la entidad, qué información puede compartir legítimamente, quién responde por su calidad y bajo qué condiciones se ejecuta una acción? Cuando estas decisiones no se toman antes de desarrollar, las integraciones se convierten en dependencias opacas. Funcionan hasta que cambia un proveedor, se ajusta una norma, se migra una plataforma o se modifica un campo de un formulario.
La interoperabilidad madura combina al menos cuatro capas. La organizacional coordina responsabilidades y acuerdos entre áreas o entidades. La semántica define qué significa cada dato y cómo debe interpretarse. La técnica habilita el intercambio mediante estándares, APIs y servicios. La legal y de seguridad establece límites para el acceso, el tratamiento y la auditoría. Si una de estas capas queda rezagada, la promesa de integración pierde valor operativo.
En el contexto colombiano, esta conversación también debe dialogar con los lineamientos de Gobierno Digital y GOV.CO, las obligaciones de accesibilidad, la protección de datos personales y la necesidad de ofrecer canales institucionales comprensibles. Una plataforma pública no puede evaluar su calidad solo por la cantidad de sistemas conectados. Debe demostrar que esas conexiones mejoran el acceso, reducen tiempos y preservan la confianza.
De intercambiar datos a orquestar servicios
El cambio más relevante consiste en dejar de pensar en transferencias puntuales de información y diseñar recorridos completos. Interoperar no es enviar una base de datos de una entidad a otra. Es permitir que un trámite active verificaciones, notificaciones y decisiones con reglas claras, minimizando solicitudes repetidas y evitando que el ciudadano actúe como mensajero entre instituciones.
Por ejemplo, una solicitud puede requerir validar identidad, consultar requisitos, revisar estado de pagos, registrar evidencia y notificar una respuesta. Cada paso puede involucrar sistemas distintos. La arquitectura adecuada no obliga a que todos compartan una misma plataforma ni replica toda la información en cada repositorio. Define, en cambio, qué sistema conserva la fuente oficial, qué servicio expone cada capacidad y cómo se registra el intercambio.
Esta diferencia reduce duplicaciones y mejora la trazabilidad. También permite evolucionar componentes sin detener el servicio completo. Si se reemplaza un gestor documental o se moderniza un portal institucional, una capa de integración bien diseñada evita que el cambio rompa procesos críticos aguas abajo.
La orquestación debe ser explícita. Los flujos necesitan reglas de reintento, manejo de errores, tiempos máximos de respuesta y rutas de atención cuando una validación automática falla. Una integración que responde correctamente en condiciones ideales no es suficiente para una operación pública, donde existen picos de demanda, sistemas heredados y casos excepcionales que requieren revisión humana.
La trazabilidad no es un requisito secundario
Cada consulta, modificación o intercambio relevante debe poder explicarse. Esto implica registrar quién solicitó una operación, qué dato se consultó, con qué propósito, cuál fue la respuesta y qué decisión se tomó a partir de ella. La trazabilidad protege a la ciudadanía y también a los equipos institucionales cuando deben atender auditorías, investigar incidentes o corregir inconsistencias.
No todos los eventos requieren el mismo nivel de detalle. Guardar información excesiva puede aumentar riesgos de privacidad y costos de operación. Por eso conviene definir políticas de registro según la criticidad del proceso, la clasificación del dato y las obligaciones normativas. La trazabilidad eficaz es proporcional, consultable y útil para tomar decisiones.
Datos confiables antes que automatizaciones ambiciosas
La inteligencia artificial puede acelerar la clasificación de documentos, orientar a los usuarios, extraer información de radicados o apoyar a funcionarios en tareas repetitivas. Sin embargo, no corrige por sí sola un ecosistema de datos inconsistente. Un agente conectado a fuentes desactualizadas puede entregar respuestas convincentes pero incorrectas, con consecuencias relevantes en un servicio institucional.
Antes de automatizar, conviene establecer un inventario realista: qué datos existen, dónde se originan, quién los administra, qué calidad tienen y cuáles pueden usarse para cada finalidad. Este trabajo suele revelar identificadores duplicados, definiciones contradictorias, catálogos incompletos y campos que ya no responden a una necesidad vigente.
La gobernanza de datos no exige crear una estructura burocrática desproporcionada. Puede comenzar con decisiones concretas: asignar propietarios de dominio, acordar diccionarios de datos, documentar reglas de validación y medir indicadores de calidad. El nivel de formalidad depende del tamaño de la entidad, del volumen transaccional y de la sensibilidad de la información.
En procesos de alto impacto, los modelos de IA deben operar con acciones acotadas, auditables y medibles. Un asistente puede orientar sobre requisitos o resumir información documental, pero una decisión administrativa debe conservar controles definidos, evidencia de sus fuentes y supervisión humana cuando el riesgo lo amerite. La automatización responsable no elimina el criterio institucional: lo enfoca donde genera más valor.
Arquitectura para convivir con lo existente
Muchas entidades no parten de cero. Conviven con sistemas misionales construidos hace años, repositorios documentales, portales institucionales, aplicaciones contratadas por áreas distintas y herramientas de análisis con capacidades limitadas de integración. Pretender reemplazar todo de una vez puede elevar el riesgo, ampliar los plazos y afectar la continuidad operativa.
Una estrategia más sostenible identifica capacidades prioritarias y las desacopla gradualmente. Las APIs pueden exponer funciones de sistemas heredados sin modificar de inmediato su núcleo. Una capa de integración puede transformar formatos, aplicar reglas de seguridad y controlar el acceso. Los portales pueden evolucionar hacia arquitecturas desacopladas cuando existe una necesidad concreta de reutilizar contenidos o atender múltiples canales.
Esto no significa que toda entidad deba adoptar una arquitectura compleja. Los microservicios, por ejemplo, aportan independencia de despliegue y escalabilidad selectiva, pero también exigen mayor disciplina de observabilidad, despliegue, versionamiento y soporte. Para un servicio de alcance limitado, un modular monolito bien mantenido puede ser una decisión más eficiente. El criterio no está en seguir una tendencia, sino en elegir una estructura que el equipo pueda operar y evolucionar.
La gestión de versiones es otro punto crítico. Una API pública o interinstitucional necesita contratos estables, comunicación anticipada de cambios y periodos de transición. Romper una integración por modificar un campo sin control puede detener procesos que no son visibles para el equipo que hizo el ajuste. La interoperabilidad requiere tratar las interfaces como productos institucionales, no como entregables puntuales.
Seguridad y acceso con propósito definido
Abrir capacidades de integración no equivale a exponer información sin restricciones. El diseño debe aplicar el principio de mínimo privilegio: cada sistema y cada usuario acceden únicamente a los datos y operaciones necesarios para cumplir una finalidad autorizada.
La autenticación fuerte, la autorización por roles o atributos, el cifrado en tránsito y la gestión segura de credenciales son controles básicos. Pero su efectividad depende de la operación: revisar permisos, rotar secretos, monitorear patrones anómalos y contar con procedimientos claros de respuesta a incidentes. La seguridad no puede aparecer al final del proyecto como una lista de verificaciones.
También es necesario diferenciar entre datos abiertos, datos compartibles bajo acuerdo y datos restringidos. La transparencia aporta valor cuando la información se publica con calidad, contexto y formatos reutilizables. Publicar datos sin metadatos o sin una actualización sostenible puede producir interpretaciones erróneas y erosionar la confianza que se buscaba fortalecer.
Cómo avanzar sin detener la operación
Los programas de interoperabilidad suelen fracasar cuando se plantean como transformaciones totales sin resultados visibles en el corto plazo. Una ruta efectiva prioriza casos de uso que combinen impacto ciudadano, viabilidad técnica y capacidad institucional para sostenerlos. Reducir documentos solicitados en un trámite frecuente puede ser un mejor primer paso que construir una gran plataforma sin adopción clara.
Cada caso debe tener métricas desde el inicio: tiempo promedio de atención, número de validaciones manuales, tasa de errores, disponibilidad del servicio, consultas exitosas y percepción del usuario. Las métricas permiten justificar inversiones y detectar dónde la integración no está resolviendo el problema esperado.
También conviene conformar equipos con responsabilidades compartidas entre negocio, tecnología, seguridad, datos y atención al ciudadano. La interoperabilidad no puede quedar exclusivamente en manos de un proveedor ni de un área de TI. Requiere decisiones institucionales sostenidas, documentación accesible y transferencia de conocimiento para evitar dependencias críticas.
Coresis aborda este tipo de retos desde tecnología aplicada con criterio de arquitectura y continuidad: integraciones que consideran la plataforma existente, los flujos editoriales y operativos, la seguridad y la evolución posterior. El valor no está en conectar por conectar, sino en construir capacidades administrables que respondan a objetivos verificables.
El futuro será más exigente para las entidades que continúen acumulando soluciones aisladas. Cada nuevo canal, automatización o servicio de IA hará más visible la calidad de sus datos y de su arquitectura. Empezar por un proceso concreto, gobernarlo bien y dejar una capacidad reutilizable puede transformar una integración puntual en una base confiable para mejores servicios públicos.