Evidencia — Modelo de referencia de ingeniería
Arquitectura de IA gobernada y agentes
Cómo situar la IA, y donde esté justificado un agente, dentro de una operación crítica para que la capacidad aumente sin que la autoridad supere a la consecuencia. La forma reutilizable del límite de control del sistema insignia — con sus compensaciones, modos de fallo y límites expuestos.
Modelo de referencia de ingeniería
Una arquitectura de referencia, generalizada a partir del sistema insignia. No es un producto ni trabajo de un cliente.
Propósito
Para qué sirve esta arquitectura.
Esta arquitectura sitúa la IA, y donde esté justificado un agente, dentro de una operación crítica para que la capacidad pueda aumentar sin que la autoridad supere a la consecuencia. Es la forma reutilizable del límite de control realizado en el Sistema gobernado de operaciones de casos.
Cuándo es apropiada
- Trabajo de alto volumen que implica leer documentos no estructurados, recuperar políticas o contexto, y redactar una evaluación fundamentada.
- Decisiones que deben ser trazables hasta una fuente y defendibles a posteriori.
- Operaciones donde algunas acciones son rutinarias y seguras de automatizar, mientras que otras tienen consecuencias y deben detenerse para un humano.
Arquitectura
Componentes, relaciones y límites.
El modelo nunca funciona solo. Es un componente dentro de un sistema determinista que decide qué ocurre a continuación y registra cada paso.
Límite de control
Descripción textual de este diagrama
El modelo o agente se sitúa dentro de un límite de control y está rodeado de la gobernanza que necesita para funcionar con seguridad: permisos acotados, las herramientas y la recuperación que puede usar, evaluación, monitorización y recuperación.
Las acciones consecuentes no salen del límite por sí solas — pasan por una puerta de aprobación humana. La autoridad es proporcional a la consecuencia.
Componentes
- Orquestador de flujo de trabajo
- El motor determinista que hace avanzar el trabajo a través de estados con nombre y decide cuándo se llama al modelo. Él, no el modelo, mantiene el control.
- Recuperación de información
- Obtiene la política y el contexto previo que una tarea necesita, con procedencia, para que el modelo trabaje a partir de material fundamentado en lugar de memoria.
- Pasarela del modelo
- La ruta única y observable hacia el modelo. Aplica minimización del contexto, límites, tiempos de espera, y registro respetuoso de la privacidad.
- Motor de políticas y reglas
- Verificaciones deterministas que la salida del modelo debe superar: citas obligatorias, contenido prohibido, y reglas de negocio.
- Registro de herramientas y acciones
- Una lista blanca de las acciones que el sistema puede realizar, cada una con alcance limitado e invocada solo por el orquestador, nunca directamente por la salida del modelo.
- Puerta de aprobación
- Un estado con nombre donde una persona con la autoridad adecuada aprueba las acciones con consecuencias antes de que salgan del límite.
- Marco de evaluación y registro de auditoría
- Mide el sistema frente a conjuntos de datos antes del lanzamiento y registra cada actor, entrada, cita y decisión en operación.
Límites de datos y autoridad
Todo el sistema funciona dentro de un límite de control. Los datos y la autoridad están acotados para que la capacidad esté contenida.
- Mínimo privilegio: cada servicio y rol posee solo los permisos que necesita; la pasarela del modelo no puede escribir en un sistema de registro.
- Contexto acotado: la pasarela envía al modelo el contexto mínimo requerido para la tarea, y registra lo que se envió.
- Acciones en lista blanca: el sistema solo puede realizar acciones del registro, y solo a través de adaptadores de integración que el límite puede ver.
- El contenido no es una orden: el texto dentro de un documento recuperado nunca puede hacer que una herramienta se ejecute; las instrucciones provienen únicamente del orquestador.
- Los secretos permanecen fuera de la ruta del modelo y se proporcionan como bindings, nunca colocados en los prompts ni en los registros.
Autoridad humana
Dónde una persona permanece al mando.
La autoridad se concede en proporción a la consecuencia de la acción. El rol humano está diseñado, no improvisado.
- Los pasos de baja consecuencia se ejecutan automáticamente dentro de límites explícitos.
- El trabajo de consecuencia media lo decide un operador con la asistencia del modelo.
- Las acciones de alta consecuencia requieren un aprobador senior en la puerta.
- Una persona siempre puede anular; la anulación, su autor y su motivo se registran.
- Una confianza baja del modelo, una verificación de política fallida, o una entrada ilegible escalan a un humano en lugar de continuar.
Evaluación
Cómo se mide, y cómo se gestiona la incertidumbre.
El sistema solo es fiable si puede medirse y mantenerse a un estándar antes y durante la operación.
Qué se mide
- Fundamentación: ¿está respaldada cada afirmación del modelo por una cita recuperada?
- Éxito de la tarea: ¿cumple la salida los criterios de aceptación de la tarea?
- Precisión y exhaustividad de las verificaciones de política: ¿se marcan las salidas correctas sin ahogar a los operadores en falsos positivos?
- Tasa de anulación humana: ¿con qué frecuencia corrigen los operadores el borrador, y por qué?
- Corrección de la escalada: ¿llegan a un humano los casos con consecuencias o de baja confianza?
- Latencia y coste por unidad de trabajo: ¿es operable a volumen?
Incertidumbre
El modelo devuelve una confianza calibrada, no una respuesta sin más. Por debajo de un umbral establecido, se abstiene y escala en lugar de adivinar. La calibración en sí se mide, porque un modelo demasiado confiado es más peligroso que uno cauteloso.
Observabilidad
Cada paso emite una traza respetuosa de la privacidad: qué estado se ejecutó, qué herramientas se llamaron, cuánto tiempo tomó, y el resultado; nunca los valores de campos confidenciales. Las métricas y trazas hacen visible una regresión antes de que se convierta en un incidente.
Modos de fallo
Cómo falla, y qué se mantiene.
| Modo de fallo | Mitigación |
|---|---|
| Salida sin fundamento o fabricada | Exigir citas, ejecutar verificaciones deterministas de política, y hacer pasar las acciones con consecuencias por un humano. Una afirmación sin respaldo no puede pasar. |
| Inyección de prompt a través de un documento recuperado | Tratar todo contenido como datos, nunca como instrucciones; las herramientas solo se ejecutan desde el orquestador; el registro de acciones está en lista blanca. |
| Uso indebido de herramientas o acciones | Limitar el alcance de los permisos de cada acción, exigir confirmación para las que tienen consecuencias, y registrar cada invocación. |
| Caída del modelo o del proveedor | Degradar de forma controlada a una cola manual; el flujo de trabajo continúa sin el modelo en lugar de que la operación falle. |
| Deriva silenciosa de la calidad | Monitorizar las métricas de evaluación en operación; una deriva más allá de un umbral desencadena una revisión y, si es necesario, una reversión. |
| Datos sensibles que llegan al modelo | Minimizar y, donde sea posible, redactar el contexto; registrar exactamente lo que se envió; mantener el límite auditable. |
Alternativas rechazadas
Qué se consideró, y por qué no se eligió.
-
Un agente totalmente autónomo sin puerta humana
Considerado Promete el mayor rendimiento y el menor esfuerzo humano.
Rechazado La autoridad superaría a la consecuencia: una sola acción errónea no podría detectarse antes de salir del límite. La autonomía se ata en cambio a la consecuencia.
-
Un único prompt grande que hace todo
Considerado Es rápido de construir y se presenta bien.
Rechazado No puede inspeccionarse, probarse ni gobernarse paso a paso, y falla de forma opaca. Se usa en su lugar un flujo de trabajo determinista con estados discretos y comprobables.
-
El ajuste fino (fine-tuning) como control principal
Considerado Un modelo ajustado puede reducir los errores obvios.
Rechazado El ajuste cambia el comportamiento en promedio pero no ofrece ninguna garantía en tiempo de ejecución. La gobernanza debe imponerse mediante recuperación, verificaciones de política y la puerta, no esperarse de los pesos.
-
Solo automatización determinista (RPA)
Considerado Es predecible y no necesita ningún modelo.
Rechazado Es frágil con documentos no estructurados y casos ambiguos, precisamente donde esta arquitectura demuestra su valor. Donde la entrada está completamente estructurada, el enfoque más simple es el correcto (véase más abajo).
Despliegue y coste
Cómo se despliega, y qué determina su coste.
- Nube del cliente o VPC
- El sistema funciona dentro del entorno del cliente con claves controladas por el cliente; los datos no salen de su límite.
- API de modelo alojada frente a modelo autoalojado
- Una API alojada es más rápida de operar y de actualizar; un modelo autoalojado ofrece control total de los datos y un coste predecible a costa de la carga operativa. La pasarela aísla esta elección para que pueda cambiar más adelante.
- Aislado o local (on-premise)
- Para los datos más sensibles, toda la ruta, incluido el modelo, funciona en un entorno aislado, aceptando un coste más alto y actualizaciones de modelo más lentas.
Coste operativo
El coste operativo está dominado por la inferencia del modelo, la infraestructura de recuperación y vectorial, y el tiempo de revisión humana, no por la orquestación en sí. El coste se describe aquí de forma cualitativa; una cifra real depende del volumen, la elección del modelo, y la tasa de revisión, y se estima por mandato en lugar de afirmarse.
Cuándo no usar esta arquitectura
Los límites, con honestidad.
- Cuando una regla, formulario o informe determinista ya resuelve el problema; no añadir un modelo por sí mismo.
- Cuando la entrada está completamente estructurada y no es ambigua; la automatización convencional es más barata y más predecible.
- Cuando la consecuencia de cualquier error residual es tan alta que un humano debe realizar toda la tarea, no solo aprobarla.
- Cuando los datos no pueden gobernarse o la operación no puede auditarse; el límite es la clave, y sin él la arquitectura no debería lanzarse.
- Cuando el volumen es demasiado bajo para justificar la evaluación y la monitorización que la arquitectura requiere para seguir siendo segura.
Lo que esto demuestra y lo que no demuestra
Demuestra
- Que la autonomía puede hacerse proporcional a la consecuencia mediante puertas y límites explícitos.
- Que los componentes de gobernanza (recuperación, validación, política, evaluación, auditoría) son arquitectura, no ocurrencias tardías.
No demuestra
- Que un modelo o marco de agente específico sea el mejor para un problema dado.
- Cifras de fiabilidad cuantitativas para una implementación particular.
Cómo inspeccionarlo
Lea la arquitectura, los límites de autoridad, los modos de fallo y la sección explícita de «cuándo no usar esto». Se realiza concretamente en el sistema insignia.
Contratación
Empiece por lo que debe cambiar.
Si la IA funciona en un prototipo pero aún no puede ser de confianza en su operación, un mandato comienza con el límite de control dentro del cual debe ejecutarse.
También puede enviar una RFP, o solicitar un acuerdo de confidencialidad primero.