Cómo diseñar un asistente de IA limitado por herramientas, permisos y contexto

El límite real de un asistente de IA es el contrato ejecutable que rodea al modelo, no una prohibición escrita en su instrucción de sistema. Decirle «no envíes este mensaje» sirve de orientación, pero no neutraliza una herramienta de envío ni una credencial con acceso excesivo. Para convertir una conversación útil en un servicio controlado, la organización debe limitar por separado cada capacidad visible, el contexto que puede consultar, la identidad con la que actúa, las operaciones disponibles y el efecto máximo que puede causar. Así, una solicitud cotidiana no hereda datos, permisos o rutas de acción ajenos a su propósito.

¿Qué se le debe permitir hacer al asistente?

El equipo debe empezar con una carta de servicio de una sola oración y convertirla en operaciones específicas con objetivos excluidos. Una plantilla útil es: «Para [usuarios elegibles], el asistente puede [familia de tareas permitida] usando [información aprobada] para producir [resultado permitido], pero no puede [resultados o decisiones excluidos]». Antes de conectar herramientas, conviene nombrar usuarios, entorno, tareas, límites de conocimiento, supervisión humana, responsable del riesgo y resultados prohibidos. AI RMF de NIST contempla precisamente la documentación de propósito, entorno, tareas, alcance, supervisión y tolerancias de riesgo.

Después, hay que sustituir verbos amplios como «ayudar» o «administrar» por capacidades observables: buscar un expediente, resumirlo, recomendar una opción, crear un borrador, actualizar un campo, enviar, borrar o aprobar. Cada verbo puede exigir datos, identidad y autoridad distintos. OWASP recomienda ofrecer solamente la funcionalidad necesaria y preferir una operación estrecha a una extensión abierta. Usar la capacidad visible como unidad de control es una síntesis editorial práctica de esa orientación y de los resultados de NIST; no es un requisito formal impuesto por ninguna de esas organizaciones.

• Defina quién puede pedir la operación y qué resultado cuenta como éxito.
• Declare datos y sistemas permitidos antes de conceder acceso.
• Separe lo que el asistente puede responder, proponer, redactar, ejecutar o nunca decidir.
• Asigne un dueño del servicio, otro de los accesos cuando corresponda y un destino humano para excepciones.

¿Qué información puede usar cada capacidad?

Cada capacidad necesita un sobre informativo: una definición de las fuentes, registros y clases de datos elegibles, no solo un presupuesto de tokens. Debe especificar sistemas aprobados, tipos de objeto, filtros de cuenta o caso, fechas, expectativas de actualidad, derechos del usuario y datos prohibidos. Los resultados Map de NIST contemplan límites de conocimiento, alcance específico y supervisión del uso de las respuestas. Si falta evidencia necesaria, está vencida o el usuario no puede consultarla, el servicio debe rechazar la respuesta o expresar su limitación; ampliar la ventana de contexto no crea autoridad ni vuelve verdadera la información.

La procedencia también importa. OWASP aconseja tratar mensajes externos, documentos, archivos adjuntos, respuestas de API y contenido recuperado como datos no confiables, separados de las instrucciones del servicio. Un texto encontrado puede aportar evidencia, pero no debe redefinir permisos ni ordenar una herramienta. El historial de sesión y la memoria persistente requieren reglas diferentes: qué puede entrar, cómo se aísla por usuario y sesión, qué se valida antes de guardar, cuándo vence, cómo se elimina y qué jamás se conserva. OWASP incluye además límites de tamaño, revisión de datos sensibles y protección de integridad, sin proponer valores universales.

• Registre la fuente, el tipo de registro, el filtro de objeto y la clasificación permitida.
• Defina una expectativa de actualidad y la conducta ante evidencia vieja o ausente.
• Separe contenido confiable de instrucciones y contenido externo no confiable.
• Aplique a la memoria reglas explícitas de elegibilidad, aislamiento, vencimiento y borrado.

¿Cómo deben aplicar el límite la identidad, las herramientas y los permisos?

La autenticación, la autorización y la aprobación deben resolverse por separado, mientras la puerta de herramientas y los sistemas de destino hacen cumplir el límite. La autenticación establece quién es el usuario, cliente o proceso. La autorización decide qué operación puede realizar sobre qué recurso. La aprobación acepta una acción propuesta concreta. La especificación de MCP ilustra esta separación mediante clientes, recursos protegidos y servidores de autorización; también recomienda alcances de privilegio mínimo y tokens ligados al recurso previsto. Es una referencia útil para integraciones MCP protegidas, no una regla universal para toda arquitectura.

El diseño debe elegir entre autoridad delegada del usuario y una identidad de carga de trabajo controlada, sin heredar silenciosamente la cuenta privilegiada de un operador. Exponga operaciones estrechas con parámetros validados, no acceso general a correo, bases de datos, navegador o shell. OWASP recomienda preservar el contexto de autorización del usuario, reducir permisos descendentes y mediar cada solicitud en el sistema de destino. NCSC añade privilegio mínimo, configuraciones seguras, restricciones de acción y salvaguardas externas. Por eso, un prompt, clasificador o guardrail en lenguaje natural puede orientar al modelo, pero no sustituye un control de autorización.

• Limite verbos, recursos, objetos, campos y destinos.
• Restrinja duración, alcance y audiencia de las credenciales.
• Valide parámetros en la ruta de ejecución.
• Defina por servicio topes de tasa, reintentos, lotes, gasto, tiempo y profundidad de cadena, además de idempotencia, reversión y corte.

La conversación puede ser continua; su autoridad debe dividirse en capacidades pequeñas y aplicadas de forma independiente.

¿Cuánta acción debe poder realizar cada capacidad?

Cada capacidad necesita un techo de acción explícito y controles independientes más fuertes conforme se acerca a cambiar el mundo exterior. Una escala editorial práctica distingue entre responder o resumir; recomendar o proponer; crear un borrador; efectuar una escritura acotada y reversible; causar una acción externa de consecuencias; y encontrarse con una decisión prohibida. NCSC recomienda restringir las acciones que la IA puede activar y añadir salvaguardas externas cuando sean necesarias. La escala traduce ese principio a decisiones operativas, pero no establece niveles obligatorios para todas las organizaciones.

La creación de un borrador debe permanecer separada del envío; una actualización reversible, de una eliminación destructiva; y una propuesta, de la decisión responsable. Para una acción de consecuencias, OWASP recomienda separar decisión y ejecución y vincular la aprobación con actor, herramienta, recurso, parámetros normalizados, momento y vencimiento. La ruta de ejecución debe comprobar nuevamente autorización y aprobación antes de actuar. Aprobar nunca concede acceso faltante, amplía permisos permanentes ni convierte una decisión prohibida en permitida, incluso cuando la interfaz haga que el proceso parezca una sola conversación.

• Muestre una vista previa inspeccionable de destinatario, recurso y parámetros.
• Mantenga pagos, concesiones de acceso, operaciones destructivas, cambios de producción y compromisos externos bajo política determinista y control humano apropiado.
• Envíe juicios profesionales o decisiones de alto impacto a especialistas calificados y a un proceso gobernado por separado.
• Si cambian los parámetros aprobados, detenga la ejecución y solicite una nueva validación.

¿Qué debe ocurrir cuando el asistente llega a un límite?

El rechazo, la ayuda parcial segura, el traspaso humano y el escalamiento de seguridad deben ser resultados explícitos del servicio, con condiciones reales de parada. NIST incluye la falla segura fuera de los límites documentados y la evaluación en condiciones parecidas al despliegue. La respuesta debe explicar el límite en lenguaje sencillo sin revelar detalles sensibles y nunca afirmar que una consulta, aprobación, herramienta o escritura tuvo éxito si no ocurrió. Cuando sea seguro, puede ofrecer un borrador, una lista de verificación o una solicitud de la información que falta.

• Tarea fuera de alcance o información no elegible.
• Autorización insuficiente o aprobación requerida.
• Evidencia ausente, vencida o incapaz de sostener la respuesta.
• Juicio especializado o decisión de política pendiente.
• Herramienta no disponible o límite operativo alcanzado.
• Señal de seguridad, como evasión de aprobación, escalamiento de privilegios, exfiltración, contaminación de memoria o abuso recursivo.

El paquete de traspaso debe incluir el objetivo original, contexto no sensible pertinente, capacidad intentada, motivo, evidencia disponible o ausente, siguiente paso propuesto e identificador de rastreo. El trabajo permanece detenido mientras actúa el responsable. Un traspaso rutinario al usuario, una aprobación comercial y un incidente de seguridad pueden compartir evidencia, pero tienen dueños y urgencias diferentes. NCSC recomienda planes de incidentes con escenarios de respuesta, escalamiento y remediación, personal preparado y registros de auditoría; ese camino operacional no debe confundirse con pedirle a un supervisor que revise un borrador.

¿Cómo se convierten estos límites en un diseño operativo?

El equipo debe completar una fila de diseño por cada operación visible y conectarla con controles ejecutables, evidencia, pruebas, métricas y responsables. La fila registra actor elegible y autenticación; sobre informativo; historial y memoria; operación estrecha; identidad actuante y alcance del recurso; techo de acción; aprobación; límites operativos; rechazo; registro; escenarios de evaluación; métrica y dueño. No basta escribir «el asistente accede al CRM». Hay que distinguir, por ejemplo, «resume un caso elegible», «crea un borrador de respuesta» y «envía una respuesta aprobada».

La guía de OWASP respalda la separación al recomendar funcionalidad y permisos mínimos. También contempla registros de decisiones, herramientas, resultados de autorización, identificadores de aprobación, versiones de política, resultados y consumo, con datos sensibles redactados. Los resultados Govern de NIST piden funciones claras, comunicación, responsabilidades humanas y de IA diferenciadas, monitoreo y revisión periódica. En conjunto, estos principios evitan que el lienzo se convierta en documentación sin efecto: cada fila debe tener un control que pueda negar, una prueba que confirme esa negación, una señal operativa y alguien con autoridad para corregir o retirar la capacidad.

¿Qué evidencia permite lanzar y seguir operando el asistente?

El lanzamiento requiere evidencia de que el servicio permitido y las denegaciones esperadas funcionan en condiciones parecidas a la operación, seguida de monitoreo y reevaluación ante cambios. AI RMF pide pruebas representativas, límites documentados, falla segura, monitoreo en producción y evaluaciones periódicas de seguridad. NCSC recomienda evaluar antes de lanzar y comunicar limitaciones y modos de falla conocidos. El conjunto debe incluir tareas positivas, acceso entre cuentas, herramientas no autorizadas, evidencia vencida, contenido recuperado contaminado, datos prohibidos, evasión de aprobación, parámetros modificados, reintentos duplicados, dependencias caídas, intentos de exfiltración y cadenas descontroladas.

• Reconstruya quién pidió qué, qué capacidad y política se aplicaron y qué versiones estaban activas.
• Registre clases de fuentes y herramientas, decisiones de autorización y aprobación, acción y resultado, sin guardar secretos ni contexto sensible ilimitado.
• Observe uso inesperado de herramientas, denegaciones repetidas, fallas de autorización, aprobaciones modificadas, secuencias anómalas, latencia, consumo y deriva.
• Asigne autoridad para pausar, modificar o retirar cada capacidad.

La evidencia no queda congelada después del lanzamiento. NCSC señala que cambios en datos, modelos e instrucciones pueden alterar el comportamiento y deben reflejarse en las pruebas; también recomienda vigilar cambios repentinos o graduales relevantes para la seguridad respetando la privacidad. Reabra las evaluaciones afectadas cuando cambien recuperación, memoria, herramientas, permisos, políticas, proveedores u operación. Empiece con la capacidad útil más pequeña y amplíe autoridad mediante cambios revisados, no solo retocando el prompt. Cuando intervengan datos sensibles, acceso privilegiado, compromisos externos o incidentes, incorpore a los responsables de seguridad, identidad, privacidad, registros, riesgo y servicio.