4. Modelo de arquitectura interoperable
Interoperar no significa concentrar todo
Un ciudadano puede verse obligado a entregar a una oficina un documento que otra oficina del mismo Estado ya emitió. Ese costo revela sistemas separados, pero no prueba que la solución sea una base única con toda la vida de cada persona. La interoperabilidad útil permite que una autoridad reciba solo la información necesaria para una finalidad legítima, compruebe su origen, registre el acceso y corrija errores. Su objetivo es disminuir trámites y mejorar decisiones sin crear un expediente total de la ciudadanía.
El diseño propuesto se organiza en servicios comunes y responsabilidades distribuidas. Puede haber estándares compartidos de identidad, intercambio, seguridad, registros de auditoría y accesibilidad. La titularidad jurídica de cada dato y la decisión sustantiva permanecen en la autoridad competente. Un municipio no obtiene derecho a consultar una historia clínica porque use la misma plataforma que un hospital provincial; un partido no recibe acceso a beneficiarios de políticas públicas porque alguno de sus miembros gobierne. La tecnología transporta una autorización previamente definida, no la crea.
La Ley 25.326 exige que los datos personales sean adecuados, pertinentes y no excesivos respecto de la finalidad; prohíbe usos incompatibles y establece medidas de seguridad. Regula cesiones y reconoce acceso y rectificación de datos por su titular. La norma incluye supuestos específicos de intercambio entre dependencias estatales dentro de sus competencias, pero eso no equivale a permiso general para combinar bases con fines nuevos. Toda conexión debe pasar un examen concreto de base legal, finalidad, minimización, retención y derechos de la persona. B06
Hay una garantía vigente que afina la propuesta tecnológica: el artículo 20 de esa ley impide que una decisión judicial o administrativa que valore conductas humanas tenga como único fundamento un perfil producido por tratamiento informatizado de datos, y declara nulo el acto contrario. Esto no equivale a prohibir toda ayuda informática ni autoriza a insertar una firma humana ficticia al final de una decisión automática. La motivación debe identificar hechos y criterios jurídicos examinados por una autoridad responsable, con posibilidad real de impugnar datos erróneos. En un trámite puramente mecánico de verificación habrá que determinar si se está valorando una conducta humana antes de invocar ese artículo; no toda operación de software cae en su supuesto. B06
Seis piezas, no seis organismos nuevos
La primera pieza es un catálogo de servicios y datos: qué organismo presta cada servicio, qué registro produce, con qué norma, a quién puede entregarlo y bajo qué condiciones. Sin catálogo, la administración compra integraciones repetidas o consulta datos sin comprender su calidad. El catálogo puede ser federado; no exige copiar todas las bases a un servidor central.
La segunda es una identidad verificable y proporcional. Hay trámites que requieren identificación fuerte y otros que permiten consulta anónima. Pedir reconocimiento facial para conocer el horario de atención sería desproporcionado. Cuando se necesita acreditar identidad, deben existir alternativas accesibles a personas sin teléfono o conectividad y procedimientos para corregir errores. El sistema no debe confundir autenticación —saber quién solicita— con autorización —definir a qué puede acceder—.
La tercera es un intercambio de datos por propósito. Una oficina que necesita verificar un requisito pide una respuesta acotada, con fundamento y fecha; no descarga toda la base de origen. Se registra organismo solicitante, usuario autorizado, finalidad, categoría de datos, respuesta y plazo de conservación. Donde sea posible, se prefiere confirmar un atributo antes que transferir un documento entero. La protección jurídica puede requerir más o menos detalle según el trámite; no hay regla técnica única que reemplace a la ley.
La cuarta es un expediente con eventos verificables. Cada decisión guarda autor, fecha, versión, fundamento, documentos utilizados, cambios y notificación. El registro debe permitir reconstruir quién modificó una prioridad o anuló una alerta. No se trata de publicar un historial personal completo: la persona interesada, el control competente y el público tendrán accesos distintos. La Ley 27.275 favorece publicidad de decisiones y documentos bajo custodia de sujetos obligados, con excepciones y procedimientos de disociación. B05
La quinta es una capa de seguridad y continuidad: copias de respaldo, control de accesos, detección de incidentes, segregación de funciones, actualización de componentes, pruebas de recuperación y procedimientos en papel o fuera de línea cuando caiga la red. Una administración que solo funciona con conexión estable puede ser menos capaz que la anterior en una zona rural o durante una emergencia. El costo de esta capa debe incluirse desde el presupuesto inicial.
La sexta es una interfaz humana de servicio. Los formularios digitales deben usar lenguaje claro, mostrar estado y ofrecer recurso. La atención presencial o asistida permite corregir errores y evita que una persona quede sin derecho por no dominar una aplicación. Un punto único de entrada es útil si conserva un responsable real detrás de cada trámite; puede ser dañino si se convierte en una pantalla que nadie responde.
Flujos y permisos por función
La arquitectura puede representarse como un flujo de mínima información:
<code>Persona → canal presencial o digital → organismo competente
↓ solicitud justificada
registro fuente de otra autoridad
↓ respuesta mínima
decisión humana/administrativa fundada
↓
notificación + acceso + rectificación/recurso
Registro de auditoría ← cada consulta, cambio y decisión
Control competente ← acceso según atribución, separado del operador</code>
El diagrama no presupone que todo intercambio esté autorizado. La flecha entre organismos existe solo si hay competencia y base legal. El operador que resuelve un trámite no debería poder alterar de modo invisible el registro de auditoría. Quien administra usuarios no debería poder certificarse a sí mismo una prestación. Una compra tecnológica debe especificar esos permisos antes de evaluar ofertas, porque reconstruirlos después de desplegar la plataforma puede ser costoso o imposible.
Compras públicas y dependencia de proveedores
La soberanía tecnológica del proyecto es capacidad de operar, comprender, auditar y sustituir sistemas críticos. No obliga a desarrollar desde cero cada componente. Un producto comercial puede ser conveniente si ofrece interoperabilidad, portabilidad de datos, seguridad verificable y salida contractual. Una solución abierta puede ser mala si carece de mantenimiento o personal capaz de auditarla. La comparación debe incluir costo de licencia, infraestructura, migración, capacitación, soporte, actualizaciones, auditoría, riesgo de interrupción y condiciones de cambio de proveedor.
El pliego debe exigir formatos de exportación documentados, titularidad y destino de datos, niveles de servicio, pruebas de recuperación, control de subcontratistas, acceso de auditoría y eliminación o devolución al término del contrato. También debe prohibir que un proveedor reutilice datos de ciudadanos para entrenamiento o fines comerciales sin base jurídica apropiada. Si el proveedor propone un modelo de IA, el contrato debe identificar versiones, registros de entrada y salida adecuados, evaluación de errores, sesgos, incidentes y proceso de suspensión. Ninguna promesa de «algoritmo imparcial» sustituye esas obligaciones.
El marco de gestión de riesgos de IA del NIST organiza actividades en gobernar, mapear, medir y gestionar. Es útil como guía voluntaria para preguntar quién responde, qué contexto se examinó, qué se midió y cuándo se retira un sistema. No es derecho argentino ni da permiso para automatizar decisiones. El examen jurídico y la autoridad democrática preceden a la prueba tecnológica. B18
Caso mínimo: no pedir dos veces un certificado
Imaginemos que una persona solicita una ayuda para reparar una vivienda y debe demostrar una condición que consta en un registro provincial. En lugar de obligarla a trasladarse para obtener un papel, la oficina municipal podría solicitar, bajo convenio y norma aplicable, una confirmación limitada del requisito. El sistema registraría la consulta, no la totalidad del expediente provincial. Si el registro está equivocado, la persona debe poder conocer el origen del dato y corregirlo; mientras tanto, la administración necesita una vía para evitar que el error automatizado cause una denegación irreversible. El ejemplo es hipotético y exige comprobar competencias, régimen de vivienda y tratamiento de datos antes de implementarse.
El ahorro estimable incluye menos viajes y tiempo de usuarios, menos carga manual y menores errores de transcripción; también aparecen costos de integración, soporte y seguridad. No se presume que el saldo sea positivo en toda comuna. Si la demanda es baja, una consulta manual segura puede ser más razonable que construir una interfaz permanente. El capítulo sobre financiación general presentará la comparación de costo de ciclo de vida; aquí se fija la prueba funcional.
La objeción más fuerte: la plataforma compartida puede ser una concentración política
La mirada de Livia. Una capa común de identidad y registros puede convertirse en punto de vigilancia o exclusión si una administración controla permisos, decide quién puede ver qué y deja sin servicio a quien no supera la autenticación. Incluso con bases separadas, los metadatos de consultas revelan hábitos y relaciones. La descentralización nominal no basta. El diseño requiere órgano responsable por cada dato, control independiente de accesos, bitácoras auditables, límite de retención, revisión periódica de finalidades, sanciones por consultas indebidas y un canal presencial efectivo. También debe publicar incidentes relevantes sin exponer a las víctimas.
La respuesta institucional es mantener funciones y permisos separados dentro de cada marco de competencias. Una infraestructura común presta transporte y seguridad; no decide el beneficio, la sanción ni la verdad del expediente. Las autoridades de control acceden por facultad legal y registran su propia actividad. La persona afectada puede ejercer derechos de acceso y rectificación. Una reforma que no pueda explicar esta arquitectura a un ciudadano en lenguaje común no está lista para operar a escala.