RV Documento técnico Material para circulación interna Mayo 2026

Arquitectura de referencia

Gobernanza de agentes de IA para equipos técnicos públicos.

Este documento deja una propuesta técnica para evaluar, adaptar e implementar internamente un primer núcleo de IA gobernada. El objetivo no es que la IA reemplace autoridad pública, sino que prepare trabajo operativo con trazabilidad, aprobación humana y controles de seguridad.

Principio rector: la IA puede clasificar, preparar, resumir, recomendar y documentar. Las acciones sensibles quedan sujetas a política, responsable designado, evidencia y aprobación.

Documento de trabajo para arquitectura, seguridad y operación
Implementación interna con acompañamiento y transferencia
Primer caso acotado reclamos e inspecciones hídricas
Sin writes iniciales lectura, borradores y aprobación

Enfoque institucional

La pregunta no es "qué modelo usamos". Es "cómo gobernamos una acción asistida por IA".

Para un equipo público, el valor aparece cuando la IA reduce trabajo manual sin romper procedimiento administrativo, protección de datos, seguridad de la información ni capacidad de auditoría.

Qué problema resuelve

  • Casos que llegan incompletos, duplicados o mal ruteados.
  • Demoras entre recepción, clasificación, derivación y primera respuesta.
  • Evidencia dispersa en correos, planillas, sistemas y capturas.
  • Uso informal de IA sin trazabilidad, criterios de riesgo ni aprobación.

Qué no promete

  • No delega potestades públicas ni reemplaza dictamen técnico o legal.
  • No requiere migrar expediente, ticketing, GIS, sensores o sistemas existentes.
  • No habilita herramientas, internet, datos sensibles o escrituras por defecto.
  • No convierte respuestas de IA en resolución administrativa.

Qué deja instalado

  • Un patrón de arquitectura para IA con controles.
  • Un primer Core operativo acotado a un flujo y equipo.
  • Una matriz de riesgo, datos, roles, aprobadores y evidencia.
  • Un camino para que el equipo técnico lo opere y extienda.

Caso inicial recomendado

Reclamos e inspecciones hídricas con aprobación humana.

El caso es deliberadamente acotado: permite medir valor operativo sin tocar de entrada sistemas críticos ni decisiones sensibles.

Escenario

Un ciudadano, inspector, área interna o sistema reporta filtración, socavón, obstrucción, desborde, mantenimiento o riesgo en acequia/canal. El caso puede llegar con texto, ubicación, foto, historial parcial o datos incompletos.

  1. Normalizar el caso en un formato común.
  2. Extraer ubicación, tipo de riesgo, urgencia y evidencia adjunta.
  3. Buscar antecedentes permitidos en fuentes definidas.
  4. Proponer clasificación, responsable y próxima acción.
  5. Preparar borrador de respuesta, derivación u orden de inspección.
  6. Pausar lo sensible hasta aprobación humana.
  7. Registrar replay, fuentes, política, aprobador y evidencia.

Resultado esperado

  • Menos tiempo en clasificación y derivación.
  • Menos casos duplicados, incompletos o sin responsable claro.
  • Mejor primera respuesta al ciudadano o usuario interno.
  • Evidencia reconstruible para auditoría, pedido de informe o revisión posterior.
  • Base técnica para escalar a otros flujos si el piloto mide bien.

Fuera del primer alcance: sanciones automáticas, decisiones sobre derechos de agua, asignación automática de recursos públicos, modificación directa de padrones o expedientes, comunicaciones externas sin aprobación y acceso a datos sensibles sin acuerdo explícito.

Arquitectura de referencia

Una capa de gobernanza entre los modelos de IA y los sistemas del organismo.

La arquitectura recomendada no empieza por automatizar escrituras. Empieza por lectura controlada, preparación de trabajo, aprobación y evidencia.

Vista conceptual

Fuentes formularios, reclamos, expediente, correo, sensores, GIS, planillas, documentos, APIs
Core de gobernanza intake, normalización, política, clasificación, enrutamiento, aprobación, evidencia
Sistemas existentes ticket, expediente, tablero, archivo, comunicación, orden operativa, reportes
cada salto evalúa identidad, alcance, riesgo, herramienta, evidencia y aprobación

Control plane

Vista operativa para ver casos, estados, responsables, aprobaciones pendientes, rechazos, pausas, errores y métricas.

Policy engine

Reglas que determinan qué puede leer, preparar, sugerir, ejecutar o bloquear cada actor según rol, área, riesgo y fuente.

Evidence ledger

Registro append-only con eventos, redacción, hash, replay ID, fuentes usadas, salida generada y decisión del aprobador.

Contrato mínimo de datos

Este contrato permite empezar con importación controlada, CSV, API de solo lectura o ambiente de prueba. La implementación final se adapta a las capacidades del organismo.

CasePacket {
  tenant_id
  case_id
  source_system
  source_reference
  reporter_type
  location
  risk_type
  urgency
  attachments[]
  allowed_context_refs[]
  requested_action
}

PolicyDecision {
  decision: allow | require_approval | deny
  reason
  approver_role
  allowed_tools[]
  blocked_fields[]
  retention_profile
}

AuditEvent {
  event_id
  replay_id
  tenant_id
  actor
  action
  policy_decision
  evidence_refs[]
  redaction_profile
  timestamp
  previous_hash
}

Seguridad, datos y cumplimiento

Los controles se diseñan antes de conectar herramientas productivas.

El primer Core debe ser seguro por defecto: mínimo acceso, trazabilidad, separación de funciones y capacidad de pausa.

Datos y privacidad

  • Inventario de datos por fuente: personales, sensibles, operativos, públicos, internos y reservados.
  • Redacción de campos no necesarios antes de enviarlos a un modelo.
  • Respuesta filtrada del lado servidor según rol, área y alcance del caso.
  • Retención definida para logs, evidencia, adjuntos y salidas generadas.
  • Modo inicial con datos anonimizados, simulados o de solo lectura.

Ciberseguridad y operación

  • Herramientas y red denegadas por defecto.
  • Allowlist explícita de sistemas, dominios, APIs y acciones.
  • Separación de entornos: desarrollo, prueba, piloto y producción.
  • Secretos fuera de cliente, logs inseguros y prompts visibles.
  • Kill switch por workflow, herramienta, proveedor, usuario o Core completo.

Threat model de trabajo

Riesgo Control recomendado Criterio de aceptación
Prompt injection en documentos o reclamos Separar contenido no confiable de instrucciones de sistema, política y herramientas. Un texto ingresado por usuario no puede habilitar herramientas ni cambiar política.
Exposición de datos personales o sensibles Minimización, redacción, permisos por campo y revisión de fuentes permitidas. El modelo recibe solo lo necesario para la tarea aprobada.
Acción equivocada en sistema crítico Modo lectura inicial, approval gate, adapters por acción y separación de funciones. Ninguna escritura productiva ocurre sin política y aprobador registrado.
Recomendación incorrecta o no verificable Fuentes vinculadas, nivel de confianza, estado de riesgo y revisión humana. Cada recomendación muestra qué evidencia la sostiene y quién la aprobó.
Auditoría incompleta Eventos append-only, replay ID, hashes, retención y export de evidencia. Un caso puede reconstruirse sin capturas informales ni memoria del operador.

Implementación interna primero

La transferencia técnica es parte del diseño, no una etapa posterior.

El equipo interno conserva ownership de infraestructura, identidad, datos, redes, operación y decisiones. REVCLI puede aportar arquitectura, baseline de políticas, diseño de controles, QA, evidencia y acompañamiento del primer Core.

Responsabilidades sugeridas

Actor Responsabilidad Decisiones clave
Equipo técnico Infraestructura, identidad, redes, secretos, ambientes, bases, integraciones y operación. Dónde corre, cómo autentica, qué conecta, cómo monitorea y cómo se pausa.
Área funcional Flujo real, prioridades, SLAs, responsables, lenguaje ciudadano y criterios de cierre. Qué casos entran, quién aprueba, qué se considera éxito y qué queda fuera.
Seguridad y legales Datos, privacidad, retención, auditoría, riesgos, proveedor, condiciones y restricciones. Qué datos se usan, cuánto se retiene, qué controles son obligatorios.
REVCLI Arquitectura, controles, policy baseline, evidencia, QA, documentación y transferencia. Cómo se implementa el patrón con un primer Core medible.

Roadmap de trabajo

  1. Definir flujo, sponsor técnico, responsable funcional y restricciones de datos.
  2. Levantar fuentes, sistemas, roles, aprobadores, riesgos y criterios de no-go.
  3. Diseñar contrato de datos, política inicial, threat model y matriz de aprobación.
  4. Construir Core en modo lectura/import-export con evidencia y aprobación.
  5. Probar con casos históricos anonimizados y usuarios nombrados.
  6. Decidir si se habilitan escrituras productivas, con qué alcance y bajo qué monitoreo.

Entregables de arquitectura

  • Diagrama de sistemas y fuentes.
  • Contrato de datos y eventos.
  • Matriz de permisos y roles.
  • Matriz de riesgos por acción.

Entregables de operación

  • Cola de casos y estados.
  • Consola de aprobación.
  • Replay y export de evidencia.
  • Runbook de pausa y fallback manual.

Criterios de aceptación

  • Sin datos fuera de alcance.
  • Sin acciones sensibles sin aprobación.
  • Sin secretos en cliente o logs inseguros.
  • Sin caso sin replay reconstruible.

Preguntas para evaluación técnica

Lo importante es salir con alcance, dueños y restricciones claras.

1. Sistemas e integración
  • Qué sistemas reciben, clasifican, derivan y cierran casos hoy?
  • Existen APIs, webhooks, exports, reportes, CSV o bases de solo lectura?
  • Qué sistema es fuente de verdad para estado, responsable y cierre?
  • Qué acciones podrían empezar como borrador sin escribir en productivo?
2. Datos, seguridad y privacidad
  • Qué datos son personales, sensibles, reservados, internos o públicos?
  • Qué campos deben redactarse antes de pasar por un modelo?
  • Qué logs se pueden conservar y por cuánto tiempo?
  • Qué herramientas, dominios y proveedores quedan permitidos o bloqueados?
3. Aprobaciones y responsabilidad
  • Qué acciones nunca deben ejecutarse sin aprobación humana?
  • Quién aprueba una respuesta, una inspección, una derivación o una comunicación externa?
  • Qué requiere doble control o separación de funciones?
  • Quién puede pausar el Core ante error, incidente o cambio de política?
4. Implementación interna
  • Qué equipo sería owner técnico del Core luego del piloto?
  • Prefieren infraestructura propia, nube privada, entorno administrado o despliegue híbrido?
  • Qué estándares internos deben cumplirse antes de un piloto?
  • Qué documentación necesitan para que arquitectura, seguridad y dirección aprueben la prueba?

Preguntas probables

Respuestas preparadas para una revisión técnica.

Estas respuestas están escritas para bajar ansiedad técnica y evitar prometer más de lo que conviene prometer en una primera conversación.

¿Por qué no usar ChatGPT, Claude o Copilot directamente?

Porque el problema público no es solo generar texto. El problema es gobernar qué datos se usan, qué acción se recomienda, quién aprueba, qué queda registrado y cómo se reconstruye el caso después. Un chat puede ayudar a redactar; un Core gobernado controla flujo, permisos, evidencia y responsabilidad.

¿Esto reemplaza expediente, ticketing, GIS, sensores o sistemas actuales?

No. La arquitectura propuesta se ubica arriba o al costado de los sistemas existentes. En una primera etapa puede operar con exports, APIs de solo lectura, datos anonimizados o importación controlada. El organismo decide si luego habilita escrituras productivas.

¿Dónde corren los datos y quién controla la infraestructura?

Eso debe definirse con el equipo técnico. El documento está planteado para implementación interna, nube privada, entorno administrado o despliegue híbrido. La decisión correcta depende de identidad, redes, clasificación de datos, proveedores autorizados, operación y compras.

¿Qué pasa si la IA se equivoca?

El diseño asume que la IA puede equivocarse. Por eso no se la convierte en autoridad final: prepara, clasifica y recomienda; las acciones sensibles requieren revisión humana. Además, cada salida debe vincular fuentes, política, aprobador y replay para corregir el flujo después.

¿Cómo evitamos filtración de datos o prompt injection?

Con minimización de datos, redacción previa, separación entre contenido no confiable y política, allowlist de herramientas, respuestas filtradas del lado servidor y denegación por defecto de red/herramientas. Ningún texto de un usuario debe poder habilitar permisos o cambiar una política.

¿Quién aprueba y quién queda responsable?

La responsabilidad no se delega al modelo. El área funcional define aprobadores y SLAs; seguridad/legal define restricciones; el equipo técnico opera la plataforma; el Core registra quién aprobó, rechazó o pidió revisión. La separación de funciones es parte del diseño.

¿Qué deberían pedirnos antes de avanzar?
  • Un flujo inicial concreto y limitado.
  • Un inventario de fuentes y datos permitidos.
  • Una matriz de acciones: preparar, recomendar, comunicar, escribir, bloquear.
  • Un threat model y criterios de aceptación.
  • Un plan de operación interna y pausa manual.

Notas para presentar

Cómo contarlo sin sonar a demo genérica de IA.

La reunión técnica se gana mostrando criterio, límites y respeto por su operación. Conviene hablar como arquitecto de control, no como vendedor de automatización.

Abrir con esto

"No vengo a proponer que una IA tome decisiones públicas. Vengo a mostrar un patrón para que el equipo técnico pueda usar IA en trabajo real con permisos, aprobación, evidencia y capacidad de pausa."

Repetir durante la reunión

  • Primero lectura, borradores y evidencia.
  • Las escrituras productivas vienen después y solo con política.
  • El equipo interno conserva ownership técnico.
  • El piloto debe poder decir go o no-go con datos.

Evitar decir

  • "La IA decide". Decir "la IA prepara y recomienda".
  • "Automatizamos todo". Decir "acotamos un flujo".
  • "Conectamos a todos los sistemas". Decir "empezamos con fuentes permitidas".
  • "Esto reemplaza". Decir "esto gobierna y documenta".

Orden recomendado si tenés 15 minutos

  1. Problema: cómo usar IA sin perder responsabilidad, trazabilidad ni seguridad.
  2. Caso acotado: reclamos e inspecciones hídricas, sin escrituras iniciales.
  3. Arquitectura: fuentes, Core de gobernanza, sistemas existentes y evidence ledger.
  4. Controles: datos, sandbox, aprobación, replay, pausa y separación de funciones.
  5. Implementación: ownership interno, diagnóstico, blueprint y prueba controlada.
  6. Cierre: pedir un flujo, un sponsor técnico, fuentes permitidas y criterios de aceptación.

Próximo paso razonable

Un diagnóstico técnico breve antes de construir.

El próximo paso no debería ser conectar todo. Debería ser producir un diagnóstico que el equipo pueda usar internamente para decidir si el primer Core tiene sentido y bajo qué condiciones.

Diagnóstico

  • Workflow priorizado.
  • Fuentes y sistemas involucrados.
  • Datos permitidos y restringidos.
  • Riesgos y controles mínimos.

Blueprint

  • Arquitectura del primer Core.
  • Contrato de datos.
  • Matriz de aprobaciones.
  • Plan de implementación interna.

Prueba controlada

  • Casos anonimizados o históricos.
  • Modo lectura o import-export.
  • Evidencia exportable.
  • Métricas y decisión go/no-go.

Frase de cierre sugerida: "Si les sirve, el primer trabajo no es venderles un sistema cerrado. Es dejarles un diagnóstico y un blueprint para que el equipo técnico pueda decidir cómo implementar IA gobernada sin perder control sobre datos, infraestructura ni decisiones sensibles."

Referencias oficiales y contexto

Fuentes usadas para orientar el material.

Las referencias se incluyen para facilitar revisión interna. No sustituyen validación legal, compras, seguridad o arquitectura del organismo.

Notas de lectura

Este material está escrito para equipos técnicos argentinos: lenguaje claro, secciones autocontenidas, alcance explícito, riesgos visibles y próximos pasos verificables. La forma importa porque el documento puede circular sin que el presentador esté presente.