Del prototipo al cambio desplegado: integrar IA con permisos limitados

1. Define la frontera de confianza

Imagina una función interna que prepara una actualización para un registro. El modelo puede leer la información estrictamente necesaria y proponer campos nuevos, pero no recibe credenciales de la base de datos ni ejecuta la modificación. La aplicación convencional conserva el control: autentica a la persona, comprueba sus permisos, valida el estado actual y decide si aplica el cambio. Esta separación reduce el impacto de una respuesta errónea o manipulada.

Dibuja el recorrido de los datos antes de escribir código. Identifica qué envía la persona, qué contexto se incorpora, qué respuesta se espera y qué sistemas podrían verse afectados. Trata el texto recuperado de documentos, tickets y registros como datos no confiables: puede contener instrucciones engañosas y no debe ampliar la autoridad del modelo. Evita incluir secretos o datos personales que no sean imprescindibles para formular la propuesta.

Define una salida de alcance reducido. Por ejemplo, en vez de pedir al modelo que actualice un registro, solicita un objeto con el identificador del registro, los campos que propone cambiar y una explicación breve. La explicación puede ayudar a quien revisa, pero no sustituye las comprobaciones del servidor. El modelo no debe decidir quién está autorizado ni qué reglas de negocio son aplicables.

Una llamada a herramientas o funciones permite que un modelo solicite operaciones disponibles en una aplicación; no convierte esa solicitud en autorización. La aplicación debe interpretar la petición como una propuesta y aplicar su propia política. Si la función elegida implica una escritura, conviene que la interfaz expuesta al modelo solo permita preparar la operación, no confirmarla.

2. Sitúa un adaptador entre el modelo y los servicios internos

El adaptador es código de la aplicación que traduce entre la petición del usuario, la interfaz del proveedor del modelo y los servicios internos. Mantiene las credenciales, limita el contexto enviado, valida la respuesta y llama a las operaciones deterministas de negocio solo después de superar las comprobaciones. Así, el modelo no se conecta directamente a la base de datos ni decide cómo se autentica una persona.

Separa responsabilidades en módulos comprensibles: autenticación y autorización; construcción del contexto; llamada al modelo; validación de la salida; presentación para revisión; y ejecución de la operación confirmada. Esta separación permite cambiar de proveedor sin reescribir las reglas de negocio y facilita desactivar la generación sin dejar inoperante la función convencional.

Establece un contrato de entrada y salida versionado. Una respuesta estructurada puede exigir campos obligatorios, tipos concretos y enumeraciones cerradas. La salida estructurada ayuda a reducir ambigüedades de formato, pero no demuestra que los valores sean correctos ni seguros. Valida el objeto en el servidor, rechaza campos desconocidos si el contrato así lo exige y comprueba además las reglas propias del dominio.

Mantén fuera del modelo las decisiones que deben ser deterministas: identidad del usuario, permisos, límites de recursos, transiciones de estado, cálculos exactos y escritura persistente. La documentación de plataformas de integración muestra patrones de conexión de modelos y flujos de trabajo, pero la configuración concreta, los conectores disponibles y sus permisos dependen del producto y deben verificarse en su documentación vigente.

3. Convierte la propuesta en una operación autorizable

La respuesta del modelo no es una orden confiable. Antes de aplicar un cambio, comprueba que cumple el esquema esperado, que el recurso pertenece al ámbito autorizado y que el usuario actual puede realizar exactamente esa operación. No infieras autorización a partir de una explicación del modelo, una categoría sugerida ni contenido encontrado en documentos.

Comprueba el estado del registro justo antes de escribir. Si ha cambiado desde que se generó la propuesta, no apliques silenciosamente valores calculados sobre una versión anterior. Puedes devolver el caso a revisión, regenerar la propuesta con el estado nuevo o presentar un conflicto para que la persona decida. La escritura debe ejecutarse con una comprobación de concurrencia adecuada al almacenamiento empleado.

Define reglas de negocio independientes del modelo. Por ejemplo, una propuesta puede ser sintácticamente válida pero no permitida porque el estado del ticket ya es cerrado. Limita la cantidad de campos modificables, rechaza valores fuera de rango y evita que el modelo introduzca identificadores de recursos que no se hayan autorizado previamente.

La revisión humana es especialmente útil cuando el cambio es sensible, difícil de revertir o afecta a otras personas. Debe ser una decisión informada: presenta los valores actuales y propuestos, indica qué campos cambiarán y permite cancelar. En contextos regulados, las obligaciones concretas dependen de la función y clasificación aplicables; las guías prácticas de AESIA se dirigen a la implementación del Reglamento de IA y se describen como recomendaciones no vinculantes, no como sustituto de la normativa.

4. Limita credenciales, herramientas y contexto

Aplica el principio de menor privilegio a cada componente: una credencial debe permitir solo las operaciones necesarias sobre los recursos necesarios. Si el flujo necesita consultar datos y proponer una actualización, separa la identidad de lectura de la que ejecuta escrituras. Mantén la segunda fuera del proceso del modelo y úsala únicamente en la ruta de aplicación controlada por el servidor.

No expongas al modelo herramientas genéricas como ejecutar consultas arbitrarias, acceder a todos los registros o invocar cualquier API interna. Expón operaciones estrechas, como obtener un resumen de un registro autorizado o preparar un cambio de categoría. Si la plataforma permite seleccionar herramientas o funciones, esa lista es una frontera de capacidad, no un sustituto de la autorización implementada por la aplicación.

Guarda claves y tokens en el mecanismo de secretos aprobado por el entorno; no los incluyas en instrucciones, registros de depuración ni respuestas al usuario. Define rotación y revocación, separa credenciales por entorno y evita reutilizar claves de desarrollo en producción. Los mecanismos de seguridad de una API, como tokens, claves o certificados, tienen distintos alcances y requisitos: verifica cuál está configurado realmente en tu plataforma y no asumas que un nombre de mecanismo implica permisos mínimos.

Reduce también la información entregada al modelo. Elimina campos irrelevantes, oculta identificadores cuando no sean necesarios y fija límites de tamaño. Revisa qué datos se envían al proveedor, las condiciones vigentes de tratamiento y retención, y las opciones disponibles para la región y el tipo de servicio contratado. Esos detalles varían según proveedor, producto, configuración y fecha; no se pueden deducir de un patrón arquitectónico general.

5. Gestiona tiempos de espera, reintentos y duplicados

Una llamada al modelo puede tardar, devolver una respuesta incompleta o fallar por una interrupción transitoria. Define un tiempo máximo y trata una respuesta que exceda ese límite como una propuesta no disponible; no ejecutes una acción basándote en un resultado parcial. Comunica un estado claro y permite volver a intentarlo sin perder la posibilidad de revisar qué se solicitó.

Distingue entre reintentar la generación y reintentar una escritura. Volver a pedir una propuesta puede producir una salida distinta; por eso, conserva el identificador de la solicitud y muestra qué propuesta se está revisando. En cambio, repetir una escritura después de un tiempo de espera puede duplicar el efecto si la primera petición sí llegó al sistema. Usa una clave de idempotencia o un mecanismo equivalente cuando el servicio lo soporte, y comprueba el resultado antes de reenviar.

Una operación idempotente produce el mismo estado efectivo si se repite bajo las mismas condiciones; no debe confundirse con repetir cualquier petición sin consecuencias. Para una escritura no idempotente, diseña una manera de detectar si ya se aplicó, por ejemplo, registrando el identificador de operación junto con el resultado. Si no puedes establecer el resultado tras un fallo, detén el reintento automático y deriva el caso a reconciliación.

Protege las escrituras frente a cambios concurrentes. Incluye una versión o condición del estado que la aplicación leyó y rechaza la escritura si ya no coincide. Define qué se puede revertir: a veces basta restaurar campos; en otros casos hay efectos externos o notificaciones que no pueden deshacerse. En esos casos, especifica una compensación y quién decide aplicarla.

6. Despliega por etapas y conserva una salida de emergencia

Prepara un entorno de pruebas con datos no productivos o debidamente protegidos y credenciales separadas. Comprueba el recorrido completo: generación de una propuesta, rechazo de una salida inválida, denegación por falta de permisos, conflicto de estado, tiempo de espera y fallo de escritura. El objetivo aquí es verificar el comportamiento de la integración elegida, no asumir que un proveedor ofrece una función de seguridad determinada.

Empieza en modo de propuesta sin ejecución: la aplicación puede generar y mostrar resultados, pero no aplicar cambios. Después habilita la confirmación para un grupo reducido o una clase limitada de operaciones, con responsables identificados. Define de antemano qué condición detiene la función, quién puede activarla o desactivarla y cómo se comunica el cambio a las personas usuarias.

La reversión debe ser una capacidad operativa real. Incluye un interruptor que desactive la generación o la ejecución de acciones sin alterar los datos existentes, una ruta convencional para completar la tarea y un procedimiento para revisar propuestas pendientes. Si se despliega mediante una API o un pipeline, separa el despliegue técnico de la publicación para usuarios y verifica qué fase permite recibir tráfico. Los detalles dependen de la plataforma concreta.

Antes de ampliar el acceso, documenta los límites conocidos, los permisos efectivos, el tratamiento de datos y las instrucciones del proveedor aplicables a la configuración elegida. Las guías de AESIA indican expresamente que sus documentos son recomendaciones no vinculantes y están sujetos a revisión; úsalas como orientación contextual, no como dictamen legal aplicable automáticamente a cualquier integración.

7. Plantilla de revisión arquitectónica

Antes de implementar, responde por escrito a preguntas que puedan verificarse en el código, la configuración o la documentación vigente. No marques una casilla como resuelta porque el proveedor anuncie una capacidad general: confirma que esa capacidad existe en el producto, la versión, la región y el nivel de servicio que usarás.

Incluye en la revisión la interfaz exacta del adaptador, el esquema de respuesta, las reglas deterministas, la identidad de cada componente, los recursos accesibles y el camino desde la confirmación hasta la escritura. Registra también los escenarios de error, el comportamiento de reintento, el método de detección de duplicados, las condiciones de concurrencia y el mecanismo para desactivar la función.

Mantén separados los hechos documentados, las decisiones de diseño y las hipótesis pendientes. Por ejemplo, que una plataforma admita llamadas a funciones no demuestra que una función concreta sea autorizable de forma independiente. Que una guía describa mecanismos de autenticación no demuestra cuáles están activos en tu despliegue. Confirma cada detalle en la documentación primaria correspondiente y en la configuración efectiva.

Para ampliar conceptos, revisa la guía de aprendizaje sobre IA, la guía de modelos locales y las fichas del glosario sobre llamada a herramientas, principio de menor privilegio, salida estructurada e inyección de prompt. Esos enlaces internos deben conducir a páginas de Inferama y complementar esta guía; no sustituyen la documentación del proveedor elegido.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.