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

Un asistente puede recibir la orden de no enviar mensajes y, al mismo tiempo, conservar una herramienta y una credencial capaces de hacerlo. Por eso, su límite real no es una prohibición escrita en el prompt: es el contrato ejecutable que define qué información entra, qué identidad actúa, qué operación puede invocarse y qué controles la detienen. Autorizar el producto como una sola pieza hace que una consulta rutinaria pueda heredar datos o facultades ajenas. La alternativa práctica es diseñar, probar y operar cada capacidad visible —buscar, resumir, redactar, actualizar o enviar— como un servicio pequeño y controlable.

¿Qué debería estar autorizado a hacer el asistente?

El equipo debería comenzar con una carta de servicio de una oración y dividirla en operaciones observables. Una fórmula útil es: “Para [usuarios elegibles], el asistente puede [familia de tareas permitida] con [información aprobada] para producir [resultado permitido], pero no puede [resultado o decisión excluidos]”. Antes de conectar herramientas, conviene registrar usuarios, entorno, tareas, límites de conocimiento, supervisión y propietario del riesgo. Esos elementos reflejan resultados de delimitación del AI RMF de NIST; la plantilla y la división por capacidad son una síntesis editorial, no un requisito de NIST.

• Reemplazá “ayudar con soporte” por buscar un caso, resumirlo, preparar una respuesta o enviarla.
• Separá recomendar de decidir, crear un borrador de publicar y actualizar campos de eliminar registros.
• Indicá los sistemas y clases de información permitidos, además de los resultados expresamente excluidos.
• Exponé la operación mínima necesaria: OWASP prefiere herramientas estrechas a extensiones abiertas cuando alcanzan para la tarea.
• Asigná un responsable capaz de suspender o revisar cada capacidad antes de ampliar su autoridad.

¿Qué información puede usar cada capacidad?

Cada capacidad necesita un sobre de información que defina datos elegibles y fronteras de confianza; un límite de contexto no es solamente un presupuesto de tokens. El diseño debe especificar sistemas, tipos de registro, clasificaciones, filtros de objeto, fechas, vigencia esperada, derechos del usuario y datos prohibidos. NIST contempla límites de conocimiento, alcance de aplicación y supervisión de los resultados. Si falta evidencia necesaria, está vencida o el usuario no puede verla, el servicio debe negarse o calificar la respuesta: agrandar la ventana de contexto no crea autoridad ni vuelve verdadero un dato sin respaldo.

• Trat á mensajes externos, adjuntos, documentos recuperados y respuestas de API como contenido no confiable, separado de las instrucciones del servicio.
• Definí por separado qué historial vive durante la sesión y qué información, si alguna, puede persistir como memoria.
• Antes de persistir, validá el contenido; aislalo por usuario y sesión y aplicá reglas propias de vencimiento, tamaño, integridad y eliminación.
• Excluí secretos, credenciales y cualquier dato cuya conservación no tenga una finalidad aprobada.
• Registrá la fuente y su estado de vigencia para que una respuesta pueda reconocer evidencia ausente o desactualizada.

¿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, y el gateway de herramientas y el sistema de destino tienen que hacer cumplir el resultado. Autenticar establece quién es el usuario, cliente o proceso; autorizar determina qué operación puede realizar sobre qué recurso; aprobar acepta una propuesta concreta. OWASP recomienda permisos posteriores mínimos, conservar el contexto de autorización del usuario y mediar cada solicitud. El modelo puede interpretar intención, pero ni el prompt ni una regla expresada en lenguaje natural reemplazan esos controles. La identidad elegida debe ser delegada por el usuario o una identidad de trabajo controlada, nunca una cuenta privilegiada heredada sin decisión explícita.

• Ofrecé operaciones parametrizadas, como leer un caso elegible o crear un borrador, en lugar de acceso general al correo, la base, el navegador o una terminal.
• Restringí verbos, recursos, objetos, campos, destinos, duración de credenciales y audiencia del token en el camino de ejecución.
• En integraciones MCP protegidas, usá alcances mínimos y tokens destinados al servidor correcto; MCP no impone la arquitectura de todas las herramientas.
• Aplicá límites propios del servicio para tasa, reintentos, cadenas, lotes, gasto y tiempo, junto con idempotencia, reversión y corte.
• Combiná mínimo privilegio y configuraciones seguras con salvaguardas externas cuando la capacidad pueda cambiar sistemas.

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

¿Hasta dónde puede actuar cada capacidad?

Cada capacidad necesita un techo de acción explícito, con controles independientes más fuertes a medida que pasa de responder a modificar un estado externo. Una escala práctica —también síntesis editorial— distingue responder o resumir, recomendar o proponer, crear un borrador, efectuar una escritura acotada y reversible, provocar una acción externa relevante y encontrar una decisión prohibida. Crear no equivale a enviar; cambiar un campo reversible no equivale a borrar; sugerir no equivale a decidir. El techo debe estar reflejado tanto en la herramienta disponible como en la política del sistema que ejecuta.

• Para una acción relevante, mostrá una vista previa inspeccionable y separá la decisión de la ejecución.
• Vinculá la aprobación con actor, herramienta, recurso, parámetros normalizados, momento y vencimiento, y volvé a validarla justo antes de actuar.
• Si cambian destinatario, contenido o parámetros, detené la ejecución y exigí una propuesta y una validación nuevas.
• Recordá que la aprobación no amplía permisos permanentes, no reemplaza la autorización posterior y no habilita decisiones prohibidas.
• Mantené pagos, otorgamiento de accesos, operaciones destructivas, cambios productivos, compromisos externos y juicios profesionales de alto impacto bajo políticas determinísticas y responsables humanos calificados.
• Definí idempotencia, reversión y circuitos de corte según el servicio, sin convertir cifras de ejemplo en umbrales universales.

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

La negativa, la ayuda parcial segura, la derivación humana y la escalada de seguridad deben ser resultados diseñados, con una condición efectiva de detención. El asistente tiene que explicar el límite en lenguaje simple sin revelar reglas sensibles y nunca afirmar que consultó una fuente, obtuvo una aprobación o realizó una escritura cuando no ocurrió. NIST contempla la falla segura fuera de los límites documentados y pruebas parecidas al despliegue. El diseño, por lo tanto, debe ensayar estas salidas con la misma seriedad que una respuesta exitosa y no depender solamente de la confianza declarada por el modelo.

• Clasificá la causa: tarea fuera de alcance, información no elegible, autorización insuficiente, aprobación pendiente, evidencia ausente o vencida, criterio especialista requerido, dependencia caída, límite operativo o señal de seguridad.
• Ofrecé únicamente la parte segura: un borrador, una lista de control o un pedido concreto de información faltante.
• Entregá al destino el objetivo original, contexto no sensible, capacidad intentada, motivo, evidencia disponible o ausente, próximo paso y un identificador de trazabilidad.
• Separá la derivación rutinaria, la aprobación del negocio y el incidente de seguridad: comparten evidencia, pero tienen responsables y urgencias diferentes.
• Probá evasión de aprobaciones, escalada de privilegios, extracción de datos, envenenamiento de memoria y abuso recursivo de herramientas.
• Detené el trabajo pendiente mientras actúa el responsable; una acción modificada requiere validación fresca.

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

El equipo debería completar una fila del lienzo de diseño por cada operación visible y conectarla con controles ejecutables, evidencia, pruebas, métricas y un responsable. La fila debe cubrir actor elegible y autenticación; sobre de información; sesión y memoria; herramienta estrecha; identidad actuante; recursos y verbos autorizados; techo de acción; aprobación; límites operativos; negativa; registro; escenarios de evaluación; métricas; derivación y propietario. Así se evita una fila vaga como “el asistente accede al CRM”. NIST respalda funciones claras, responsabilidades diferenciadas, monitoreo y revisión; el lienzo concreto es una adaptación editorial de esos principios y de la minimización propuesta por OWASP.

Consideremos un asistente interno para personal de soporte que consulta casos aprobados y prepara respuestas, pero no decide compensaciones, modifica derechos del cliente ni emite determinaciones regulatorias. Resumir, redactar y enviar pueden aparecer en la misma conversación, aunque necesitan datos, herramientas y permisos diferentes. El registro debe permitir reconstruir decisión, herramienta, autorización, aprobación, versión de política y resultado, con datos sensibles ocultos y sin conservar secretos ni contexto ilimitado.

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

El lanzamiento requiere evidencia de que funcionan tanto el servicio permitido como las negativas esperadas en condiciones semejantes a la operación real. NIST contempla pruebas representativas, monitoreo productivo, límites documentados y falla segura; el NCSC recomienda evaluación de seguridad previa y comunicación de fallas conocidas. La batería debe combinar tareas normales con acceso entre cuentas, herramientas no autorizadas, evidencia vencida, contenido recuperado malicioso, datos prohibidos, evasión de aprobación, parámetros cambiados, reintentos duplicados, dependencias caídas, intentos de extracción y cadenas descontroladas. Un resultado aprobado demuestra lo probado, no una garantía permanente.

• Registrá quién pidió qué, qué capacidad y política se aplicaron, qué clases de fuentes y herramientas participaron, qué autorización y aprobación se resolvieron y cuál fue el resultado.
• Incluí versiones de modelo, prompt, recuperación, memoria, herramienta y política necesarias para investigar, sin guardar secretos ni contenido sensible sin finalidad aprobada.
• Observá uso inesperado de herramientas, negativas repetidas, fallas de autorización, aprobaciones modificadas, secuencias anómalas, deriva, latencia, consumo y errores según el riesgo y la privacidad.
• Asigná responsables diferentes para comportamiento del servicio, permisos de acceso, derivaciones de negocio e incidentes de seguridad, con autoridad para pausar o retirar una capacidad.
• Reabrí las pruebas afectadas cuando cambien modelos, instrucciones, recuperación, memoria, herramientas, permisos, políticas, datos, proveedores o contexto operativo.

La expansión debería comenzar con la capacidad útil más pequeña y avanzar mediante cambios revisados, no mediante una edición aislada del prompt. Cuando haya datos sensibles, memoria persistente, accesos privilegiados, compromisos externos, acciones destructivas o respuesta a incidentes, deben participar los responsables internos de seguridad, identidad, privacidad, gestión documental, riesgo y servicio. Las decisiones jurídicas, regulatorias y otros juicios profesionales de alto impacto corresponden a especialistas calificados y a procesos gobernados por separado. Esa disciplina mantiene visible quién puede actuar, con qué evidencia y bajo qué condiciones debe detenerse el servicio.