Cómo diseñar un asistente de IA acotado: herramientas, permisos y límites de contexto

El límite real de un asistente de IA es el contrato de servicio que sus componentes pueden ejecutar, no una prohibición escrita en el prompt. Si dispone de una herramienta, una credencial y una ruta para enviar un mensaje, pedirle en lenguaje natural que no lo haga no equivale a impedirlo. El diseño debe separar cada capacidad visible —buscar, resumir, redactar, actualizar, enviar, borrar o aprobar— y asignarle datos, identidad, permisos, controles y responsables propios.

¿Qué se le debe permitir hacer al asistente?

El equipo debe empezar por una carta de servicio de una sola oración y descomponerla en operaciones concretas. Una fórmula útil es: «Para [usuarios habilitados], el asistente puede [familia de tareas] con [información aprobada] para producir [resultado permitido], pero no puede [objetivos excluidos o decisiones consecuenciales]». AI RMF Core de NIST respalda documentar propósito, entorno, tareas, límites de conocimiento, alcance, supervisión humana y tolerancia al riesgo, aunque esta fórmula es una síntesis editorial práctica, no una exigencia del marco.

Verbos amplios como «ayudar» o «gestionar» esconden autoridades diferentes. Conviene convertirlos en capacidades observables: buscar un expediente habilitado, resumirlo, recomendar un paso, crear un borrador, modificar determinados campos o enviar una comunicación ya aprobada. Para cada una hay que nombrar usuarios, entorno, resultado, información admisible, supervisión, dueño del riesgo y resultados prohibidos antes de conectar herramientas. OWASP aconseja ofrecer la funcionalidad mínima y preferir una operación estrecha frente a una extensión abierta.

• Definí qué pedido puede realizar el usuario y qué resultado cuenta como éxito.
• Separá lectura, propuesta, borrador, escritura, envío, eliminación y aprobación.
• Anotá expresamente las decisiones que deben permanecer fuera del servicio.
• Asigná un responsable con autoridad para limitar, pausar o retirar la capacidad.

¿Qué información puede usar cada capacidad?

Cada capacidad debe operar dentro de un sobre de información, no apenas dentro de un presupuesto de tokens. Ese sobre especifica sistemas y tipos de registro habilitados, clasificaciones, filtros por objeto, períodos, vigencia esperada, derechos del usuario y datos prohibidos. Los resultados Map de NIST contemplan límites de conocimiento, alcance de aplicación y supervisión sobre el uso de las salidas. Ampliar la ventana de contexto no concede autoridad ni vuelve verdadera una afirmación sin respaldo.

También hay que clasificar la confianza de cada entrada. OWASP aconseja tratar mensajes externos, documentos, adjuntos, respuestas de API y contenido recuperado como material no confiable, separado de las instrucciones del servicio. La historia de la sesión y la memoria persistente requieren reglas diferentes: qué puede ingresar, cómo se aísla por usuario y sesión, qué se valida antes de persistir, cuándo vence, cómo se elimina y qué nunca se almacena. Si falta evidencia habilitada o está desactualizada, la respuesta debe rechazar o calificar el resultado.

• Fuentes, registros, campos, fechas y clasificaciones habilitadas.
• Derechos del usuario y filtros por cuenta, caso u otro objeto.
• Contenido no confiable que nunca puede convertirse en instrucción.
• Reglas separadas para sesión, memoria persistente, vencimiento y borrado.
• Conducta prevista cuando la evidencia está ausente, inaccesible o vencida.

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

Autenticación, autorización y aprobación deben resolverse por separado, y los límites tienen que aplicarse en la pasarela de herramientas y en el sistema de destino. La autenticación establece quién es el usuario, cliente o proceso. La autorización determina qué operación puede realizar esa identidad sobre qué recurso. La aprobación acepta una propuesta concreta. Para actuar, el servicio debe elegir explícitamente entre autoridad delegada del usuario y una identidad de carga controlada, sin heredar silenciosamente una cuenta privilegiada.

La herramienta expuesta debería aceptar una operación estrecha y parámetros validados, no acceso general al correo, la base de datos, el navegador o una consola. La ruta de ejecución debe limitar verbos, recursos, objetos, campos, destinos, duración de credenciales y audiencia del token. OWASP recomienda permisos mínimos y mediación completa en los sistemas de destino. En integraciones MCP protegidas, su especificación ilustra la separación de roles, los alcances de mínimo privilegio y la vinculación con el recurso previsto; no es una receta universal para toda arquitectura.

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

¿Cuánta acción puede ejecutar una capacidad?

Cada capacidad necesita un techo de acción explícito, con controles independientes más fuertes a medida que pasa de informar a cambiar el estado externo. Una escala editorial práctica distingue: responder o resumir; recomendar o proponer; crear un borrador; efectuar una escritura acotada y reversible; causar una acción externa consecuencial; o encontrarse con una decisión prohibida. La escala traduce principios de mínimo privilegio y restricción de acciones; no es una clasificación obligatoria de NIST, NCSC u OWASP.

• Separá el borrador del envío y la propuesta de la decisión responsable.
• Diferenciá una actualización reversible de una modificación destructiva.
• Fijá límites propios de tasa, reintentos, lotes, gasto, tiempo y profundidad de cadena.
• Usá idempotencia, reversión y disyuntores donde el servicio los necesite.
• Mantené pagos, accesos, producción, destrucción y compromisos materiales bajo política determinista y control humano competente.

Antes de una acción consecuencial, el usuario debe poder inspeccionar exactamente qué se ejecutará. OWASP aconseja separar decisión y ejecución y vincular la aprobación con actor, herramienta, recurso, parámetros normalizados, momento y vencimiento. Cualquier cambio de destinatario, contenido o parámetro exige una validación nueva. La aprobación nunca proporciona una autorización ausente, amplía un permiso permanente ni convierte una decisión prohibida en permitida. El sistema de destino debe volver a comprobar la autorización al ejecutar.

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

El rechazo, la ayuda parcial segura, la derivación humana y la escalada de seguridad deben ser resultados explícitos del servicio, con condiciones reales de detención. NIST contempla la falla segura fuera de los límites documentados y la evaluación en condiciones parecidas al despliegue. El asistente debe explicar el límite en lenguaje claro, sin revelar detalles sensibles de política, y nunca afirmar que consultó una fuente, obtuvo aprobación, usó una herramienta o realizó una escritura cuando eso no ocurrió.

• Tarea fuera de alcance o información no habilitada.
• Autorización insuficiente o aprobación pendiente.
• Evidencia ausente, inaccesible o desactualizada.
• Juicio especializado o decisión responsable requerida.
• Dependencia caída, límite operativo alcanzado o señal de seguridad.

La salida segura puede ser un borrador, una lista de verificación o un pedido de información faltante, nunca una forma indirecta de completar la acción denegada. La derivación debe incluir objetivo original, contexto no sensible, capacidad intentada, motivo, evidencia disponible o faltante, próximo paso y un identificador de traza. Una consulta rutinaria, una aprobación comercial y un incidente de seguridad tienen responsables y urgencias diferentes. NCSC recomienda planes de incidentes con respuesta, escalada, remediación, personal preparado y registros adecuados.

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

El equipo debe completar una fila del lienzo de diseño por cada operación visible y conectarla con controles ejecutables, evidencia, pruebas, métricas y responsables. La fila registra actor y autenticación, sobre de información, sesión y memoria, herramienta estrecha, identidad actuante, recursos autorizados, techo de acción, aprobación, límites operativos, rechazo, evidencia reconstruible, escenarios de evaluación, señales de producción y dueño. El lienzo es una síntesis editorial respaldada por principios de NIST y OWASP, no una lista normativa.

Los registros deben permitir reconstruir quién pidió qué, qué capacidad y política se aplicaron, qué clases de fuentes y herramientas intervinieron, qué autorizaciones y aprobaciones se resolvieron, cuál fue el resultado y qué versiones estaban activas. OWASP incluye decisiones, llamadas a herramientas, autorizaciones, identificadores de aprobación, versiones, resultados, consumo y anomalías entre las señales útiles, con datos sensibles redactados. No corresponde guardar secretos ni contexto ilimitado: acceso, detalle y conservación dependen de las reglas de privacidad, seguridad y gestión documental.

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

El lanzamiento requiere evidencia de que funcionan tanto el servicio permitido como las denegaciones previstas en condiciones parecidas al uso real. NIST contempla pruebas representativas, límites documentados, falla segura, monitoreo en producción y evaluación regular; NCSC recomienda evaluar la seguridad antes de liberar el sistema y comunicar limitaciones conocidas. La batería debe incluir tareas válidas, acceso entre cuentas, herramientas no autorizadas, evidencia vencida, contenido recuperado contaminado, datos prohibidos, elusión de aprobación, parámetros cambiados, reintentos duplicados, dependencias caídas, extracción de datos y cadenas descontroladas.

• Resultado permitido, denegación esperada, detención y derivación.
• Uso inesperado de herramientas, fallas de autorización y aprobaciones modificadas.
• Secuencias anómalas, deriva, latencia, consumo y fallas de dependencias.
• Responsables del servicio, de los accesos, de las derivaciones comerciales y de los incidentes.
• Autoridad clara para pausar, corregir, limitar o retirar cada capacidad.

La evidencia no queda cerrada el día del lanzamiento. NCSC señala que cambios en datos, modelos e instrucciones pueden alterar el comportamiento y deben reflejarse en pruebas y evaluaciones; también recomienda observar cambios repentinos o graduales respetando la privacidad. Conviene reabrir la parte afectada cuando cambien el modelo, el prompt, la recuperación, la memoria, las herramientas, los permisos, las políticas, los datos, el proveedor o el entorno operativo. La profundidad de la revisión debe seguir el alcance y el riesgo del cambio.

Empezá por la capacidad útil más pequeña y ampliá la autoridad mediante cambios revisados, no mediante retoques aislados del prompt. Involucrá a responsables de seguridad, identidad, privacidad, registros, riesgo y operación cuando haya información sensible, memoria persistente, acceso privilegiado, compromisos externos, cambios destructivos o respuesta a incidentes. Las decisiones legales, regulatorias u otros juicios profesionales de alto impacto deben derivarse a especialistas habilitados y a un proceso gobernado por separado.