Cómo diseñar un asistente de IA acotado 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 sus instrucciones. Si el servicio conserva una herramienta para enviar mensajes y una credencial capaz de usarla, pedirle al modelo que no envíe nada no elimina esa autoridad. El diseño debe separar cada capacidad visible —consultar, resumir, proponer, redactar, actualizar o enviar— y asignarle datos, identidad, permisos, controles, pruebas y responsables propios.

¿Qué debe poder hacer el asistente?

El equipo debe comenzar con una carta de servicio de una sola frase y convertirla en capacidades concretas. Una fórmula útil es: “Para [usuarios elegibles], el asistente puede [familia de tareas] con [información aprobada] para producir [resultado permitido], pero no puede [no objetivos o decisiones consecuenciales]”. La carta debe precisar usuarios, entorno, tareas, conocimiento permitido, supervisión y riesgos a cargo. AI RMF de NIST respalda la documentación de esos elementos, aunque el método por capacidad presentado aquí es una síntesis editorial, no un requisito de NIST u OWASP.

• Reemplace “ayudar” o “gestionar” por operaciones observables: buscar, resumir, recomendar, redactar, actualizar, enviar, borrar o aprobar.
• Defina qué cuenta como éxito para cada operación y cuáles resultados están expresamente excluidos.
• Mantenga fuera las herramientas abiertas cuando una operación estrecha sea suficiente.
• Nombre antes de la conexión quién responde por el servicio, los accesos, el riesgo y los escalamientos.

¿Qué información puede usar cada capacidad?

Cada capacidad necesita una envolvente de información: el conjunto explícito de datos que puede consultar y las fronteras de confianza que debe respetar. Esta definición incluye sistemas aprobados, tipos de registro, clasificaciones, filtros por objeto o cuenta, fechas, vigencia esperada, derechos del usuario y datos prohibidos. Una ventana de contexto más grande no crea autoridad ni vuelve verdadera una afirmación sin respaldo. Si falta evidencia necesaria, está desactualizada o no es accesible para el actor, el servicio debe limitar su respuesta, pedir información admisible o negarse.

• Trate documentos recuperados, adjuntos, mensajes externos y respuestas de API como contenido no confiable, nunca como instrucciones nuevas.
• Separe el historial temporal de la memoria persistente y defina elegibilidad, aislamiento por usuario y sesión, validación, vencimiento, tamaño y eliminación.
• Excluya de la memoria credenciales, secretos y cualquier dato que la política del servicio prohíba conservar.
• Registre la fuente y su vigencia sin copiar de manera ilimitada el contenido sensible.

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

La autenticación, la autorización y la aprobación deben resolverse por separado y aplicarse fuera del modelo. La autenticación establece quién es el usuario, cliente o carga de trabajo; la autorización decide qué operación puede ejecutar sobre cuál recurso; la aprobación acepta una propuesta específica. El equipo debe escoger de forma explícita entre autoridad delegada del usuario y una identidad de servicio controlada, sin heredar en silencio una cuenta privilegiada. La pasarela de herramientas y el sistema de destino deben validar identidad, recurso, verbo, campos y parámetros en cada ejecución.

• Exponga “leer resumen de caso” o “crear borrador”, no acceso general al correo, la base de datos, el navegador o la consola.
• Limite recursos, objetos, campos, destinos, duración de credenciales y audiencia del token.
• Defina topes propios para frecuencia, reintentos, lotes, duración, gasto y profundidad de cadenas, junto con idempotencia, reversión y corte.
• En integraciones MCP protegidas, aplique alcances mínimos y valide que el token corresponda al servidor destinatario; no generalice ese protocolo a todas las herramientas.

La conversación puede ser continua; la autoridad debe permanecer dividida en capacidades pequeñas y verificables.

¿Hasta dónde puede actuar cada capacidad?

Toda capacidad necesita un techo de acción explícito y controles independientes más fuertes cuando pasa de informar a cambiar el estado externo. Una escala práctica distingue entre responder o resumir; recomendar o proponer; crear un borrador; realizar una escritura reversible y acotada; producir un efecto externo consecuencial; y encontrar una decisión prohibida. Esta escala es una síntesis editorial apoyada en los principios de funcionalidad mínima, separación entre decisión y ejecución, mínimo privilegio y salvaguardas externas; no es un esquema obligatorio ni una tabla universal de riesgos.

• Mantenga el borrador separado del envío, la propuesta separada de la decisión y la actualización reversible separada de la eliminación.
• Antes de una acción consecuencial, muestre una vista previa verificable y vincule la aprobación con actor, herramienta, recurso, parámetros normalizados, momento y vencimiento.
• Valide nuevamente autorización y aprobación al ejecutar; si cambia el destinatario o el contenido, solicite una aprobación nueva.
• Una aprobación nunca amplía permisos permanentes, subsana una autorización faltante ni permite una decisión prohibida.

Pagos, concesión de accesos, operaciones destructivas, cambios en producción, compromisos externos materiales y juicios profesionales de alto impacto deben permanecer bajo políticas determinísticas y control humano calificado apropiados para la organización. El asistente puede preparar información o una propuesta cuando esa capacidad esté autorizada, pero no debe asumir la decisión responsable. El nivel exacto de revisión, autenticación adicional, reversibilidad y respuesta a incidentes debe definirse según el servicio; las fuentes no ofrecen umbrales numéricos universales.

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

La negativa, la ayuda parcial segura, el traslado a una persona y el escalamiento de seguridad deben diseñarse como resultados normales del servicio, con condiciones reales de parada. La respuesta debe indicar el límite en lenguaje claro sin revelar reglas sensibles y nunca afirmar que una consulta, aprobación, escritura o llamada a una herramienta tuvo éxito si no ocurrió. Cuando exista una parte segura, el asistente puede entregar un borrador, una lista de verificación o una solicitud de información faltante, pero debe detener cualquier ejecución pendiente.

• Clasifique el motivo: tarea fuera de alcance, información no elegible, autorización insuficiente, aprobación requerida, evidencia faltante o vencida, juicio especializado, dependencia no disponible, límite operativo o señal de seguridad.
• Entregue al responsable el objetivo original, contexto no sensible, capacidad intentada, motivo, evidencia disponible o faltante, siguiente paso y un identificador de trazabilidad.
• Separe el traslado rutinario al servicio, la aprobación de negocio y el incidente de seguridad: pueden compartir evidencia, pero tienen responsables y urgencias diferentes.
• Exija validación nueva si la acción propuesta cambia mientras espera atención.

Las señales de evasión de aprobación, escalamiento de privilegios, extracción de datos, envenenamiento de memoria o uso recursivo de herramientas justifican una ruta de seguridad, no una simple conversación aclaratoria. El plan operativo debe identificar quién recibe la alerta, qué se suspende, cómo se revocan accesos y quién decide reanudar, modificar o retirar la capacidad. NCSC recomienda planes con respuesta, escalamiento, remediación, personal preparado y registros de auditoría; la organización debe adaptar esa estructura a su arquitectura y nivel de riesgo.

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

El equipo debe completar una fila del lienzo por cada operación visible y conectar cada decisión con controles ejecutables, evidencia, pruebas, métricas y responsables. La fila debe registrar actor elegible y autenticación; envolvente de información; historial y memoria; operación estrecha; identidad actuante y alcance; techo de acción; aprobación; límites y cortes; negativa; registro; escenarios de evaluación; métricas; escalamiento y propietario. “El asistente accede al CRM” no sirve como capacidad: “resumir un caso que el asesor ya puede consultar” sí permite verificar permisos y resultados.

Considere un asistente interno para personal de soporte que consulta información aprobada y prepara respuestas, pero no decide compensaciones, cambia derechos del cliente ni formula determinaciones regulatorias. Sus tres capacidades pueden compartir la misma conversación, aunque deben conservar datos, herramientas, permisos, techos, pruebas y destinos de escalamiento separados. Los registros deben permitir reconstruir la ejecución con identificadores de política, evidencia y resultado, sin almacenar secretos ni copiar conversaciones sensibles de forma ilimitada.

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

La liberación requiere evidencia de que las tareas permitidas funcionan y de que las negativas, paradas y rutas de escalamiento responden correctamente en condiciones parecidas al despliegue. El conjunto debe combinar escenarios positivos con acceso entre cuentas, herramientas no autorizadas, evidencia vencida, contenido recuperado manipulado, datos prohibidos, evasión de aprobación, parámetros alterados, reintentos duplicados, fallas de dependencias, intentos de extracción y cadenas descontroladas. Un resultado aprobado describe una versión y un entorno concretos; no ofrece garantía permanente.

• Haga reconstruibles el solicitante, la capacidad, la política, las clases de fuente y herramienta, las decisiones de autorización y aprobación, el resultado y las versiones activas.
• No registre secretos ni contexto sensible ilimitado; defina acceso, redacción y conservación según privacidad, seguridad y gestión documental.
• Observe por capacidad usos inesperados, negativas repetidas, fallas de autorización, cambios de aprobación, secuencias anómalas, latencia, consumo y fallas.
• Asigne responsables distintos para comportamiento del servicio, concesión de accesos, traslados de negocio e incidentes, con autoridad para pausar o retirar.

Los cambios materiales deben reabrir las pruebas y la evidencia de las capacidades afectadas. Esto incluye modificaciones en modelos, instrucciones, recuperación, memoria, herramientas, permisos, políticas, datos, proveedores o contexto operativo. NCSC señala expresamente que los cambios en datos, modelos e instrucciones pueden alterar el comportamiento y recomienda actualizar la evaluación, además de monitorear variaciones relevantes respetando la privacidad. Empiece con la capacidad útil más pequeña y amplíe su autoridad mediante cambios revisados, no mediante una edición aislada del mensaje de sistema.

Cuando una capacidad toque información sensible, memoria persistente, acceso privilegiado, compromisos externos, cambios destructivos o respuesta a incidentes, deben participar los responsables internos de seguridad, identidad, privacidad, gestión documental, riesgo y operación del servicio. Los asuntos legales, regulatorios y otros juicios profesionales de alto impacto corresponden a especialistas calificados y a procesos gobernados por separado. Esta coordinación no sustituye los límites técnicos: asegura que cada excepción llegue a quien realmente tiene autoridad y responsabilidad para resolverla.