Integrar la IA en el sistema de información sin crear otro sistema incontrolable

El riesgo: un sistema paralelo sin responsable

Un asistente suele empezar con unos documentos y una clave API. Se vuelve útil, recibe acceso al CRM, conserva conversaciones y ejecuta acciones hasta asumir parte de un proceso de negocio. Si estas ampliaciones escapan a las reglas del sistema de información, la empresa obtiene un segundo sistema: datos duplicados, identidades implícitas, dependencias poco conocidas y operación sin responsable. La tarea de la dirección de sistemas es definir cómo se incorpora esa capacidad al sistema existente.

Nuestra recomendación de ingeniería es tratar la IA como un componente del sistema de información. El modelo aporta una capacidad probabilística; los contratos, permisos, estados y compromisos de servicio siguen siendo explícitos. Lo que sigue es un método de diseño, no un balance de resultados medidos en proyectos de Digital Place.

Empezar por el servicio y sus responsabilidades

Describa primero el servicio: usuario, evento desencadenante, datos necesarios, salida esperada, acciones posibles y modo degradado. Un asistente de preparación de expedientes puede generar una síntesis con fuentes sin disponer de permiso para modificar el expediente. Una automatización puede sugerir una categoría sin decidir el rechazo de una solicitud. Estas distinciones fijan los límites antes de escoger un modelo o framework.

Asigne responsables de negocio, tecnología y operación. Defina quién acepta una nueva fuente, permiso o comportamiento. El perfil GenAI del NIST aporta un marco de gestión de riesgos; aplicarlo requiere decisiones locales verificables.

Contratos utilizables por el sistema

Sitúe una API de servicio delante del entorno de ejecución de IA. Versione entradas, esquemas de salida, errores y reglas de idempotencia. Un JSON válido puede contener información errónea: complemente la validación del esquema con controles de negocio, referencias y tratamiento explícito de valores desconocidos. Evite que cada consumidor dependa del formato de un proveedor.

OpenAPI permite describir interfaces HTTP. El contrato debe precisar también límites de tamaño, tiempos de espera, reintentos, cancelación y entrega asíncrona cuando proceda. Tras agotarse la espera de una escritura, compruebe el estado antes de repetirla: el segundo intento no debe generar un segundo compromiso de negocio.

Datos y RAG: gobernar la recuperación

Utilice recuperación documental cuando la respuesta dependa de información interna o cambiante. Un RAG no corrige automáticamente la calidad de las fuentes: siguen siendo necesarios inventario, responsables, fechas, permisos y eliminación. Mantenga una referencia al documento y al fragmento utilizado; pruebe también la ausencia de resultados y las contradicciones.

Los permisos deben aplicarse durante la recuperación. Un índice compartido que expone un documento a un usuario no autorizado produce una fuga, aunque la respuesta parezca útil. Propague retiradas de acceso y eliminación a índices y cachés. Trate el contenido recuperado como datos no fiables, nunca como instrucciones capaces de ampliar permisos.

Identidades y autorización de acciones

Distinga identidad del usuario, identidad del servicio y delegación concedida al agente. Cada herramienta debe verificar la autorización sobre el recurso concreto con un alcance limitado. Un token amplio dentro de una instrucción no es una delegación controlada. Los secretos permanecen en el servidor, con rotación y destinatario definido.

En conectores MCP, la especificación de autorización 2025-11-25 describe mecanismos del transporte HTTP. No sustituye la autorización de negocio dentro de cada herramienta. Una acción sensible debe comprobarse en su ejecución; la aprobación humana debe vincular los parámetros exactos a un estado todavía válido.

Intercambiabilidad con pruebas de comportamiento

Aísle proveedores tras un adaptador reducido: invocación, salidas estructuradas, herramientas, errores y contabilidad de uso. Versione instrucciones, políticas y conjuntos de evaluación. Pruebe un modelo alternativo con los mismos escenarios y registre diferencias de calidad, latencia, capacidades y condiciones de tratamiento.

Una API compatible no garantiza un comportamiento equivalente. La reversibilidad exige además exportar datos, reconstruir índices, repetir evaluaciones y eliminar copias del proveedor según los contratos. Prepare una salida practicable antes de que las optimizaciones específicas se vuelvan imprescindibles.

Costes y ejecución: medir el expediente terminado

Siga el coste por tarea completada, la latencia total, las invocaciones, los reintentos, el consumo de contexto y los casos derivados a revisión humana. Un precio bajo por token puede ocultar procesos largos o muchas correcciones humanas. Pruebe cargas realistas con documentos extensos, herramientas lentas y colas; fije presupuestos de invocaciones, tiempo y gasto por ejecución.

Elija el método más sencillo que cumpla los criterios: regla determinista, búsqueda, extracción, llamada a un modelo o agente acotado. Prevea un mecanismo de corte y un modo manual. Si falla una dependencia, el servicio debe expresar su limitación y conservar un estado coherente, sin inventar certezas.

Observabilidad útil y minimización

Correlacione solicitudes, recuperación, modelo, decisiones de control e invocaciones. Las convenciones HTTP de OpenTelemetry ofrecen referencias de instrumentación; las convenciones GenAI evolucionan en su repositorio específico. Fije una versión y no convierta una convención experimental en contrato duradero.

Las trazas deben permitir diagnosticar sin convertirse en otra base de datos personales. Registre versiones, duraciones y motivos de control; limite contenidos y oculte secretos. Defina accesos, conservación y procedimientos de incidente antes de activar capturas detalladas.

Evaluación, CI/CD y operación

Construya escenarios representativos: respuesta correcta, fuente ausente, acceso denegado, inyección, fallo de herramienta, recuperación y cancelación. Pruebe esquemas y controles de forma determinista; repita ensayos del modelo para valorar su variabilidad. Separe conjuntos de desarrollo y validación y examine errores por gravedad, sin reducirlos a una sola media.

Un cambio de modelo, instrucción, índice o herramienta es un cambio de software. El pipeline, los artefactos versionados, la evaluación, el despliegue gradual y la reversión deben cubrir el servicio completo. El perfil SSDF del NIST para IA ayuda a incorporar el desarrollo seguro al ciclo de vida.

Una decisión explícita de puesta en servicio

Antes de abrir el servicio, exija pruebas: contratos estables, accesos comprobados, datos identificados, presupuestos respetados, escenarios adversarios ejecutados, responsables de operación definidos y restauración ensayada. Defina SLO, criterios de suspensión y frecuencia de reevaluación. Una demostración satisfactoria por sí sola no acredita esos elementos.

Así, la IA entra en el sistema de información con capacidades y límites conocidos. Para Digital Place, los fundamentos de ingeniería hacen controlable la integración: una responsabilidad, una interfaz y una prueba en cada punto de integración relevante.