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 el prompt. Si el sistema conserva una herramienta y una credencial capaces de enviar un mensaje, decirle «no lo envíes» no elimina esa posibilidad. El diseño debe precisar qué información puede entrar, con qué identidad opera cada herramienta, qué acción puede ejecutarse, qué aprobación corresponde y cuándo el servicio tiene que detenerse. Así, una conversación fluida no se convierte accidentalmente en autoridad amplia.

¿Qué se le debe permitir hacer al asistente?

El equipo debe comenzar con una carta de servicio de una sola oración y convertirla en operaciones concretas. Una fórmula útil es: «Para [usuarios elegibles], el asistente puede [familia de tareas permitida] usando [información aprobada] para producir [resultado permitido], pero no puede [objetivos excluidos o decisiones consecuentes]». Antes de conectar herramientas, la carta debe identificar el entorno de uso, la supervisión humana, los límites de conocimiento y quién asume el riesgo operativo.

La unidad práctica de control es una capacidad específica y visible para el usuario, no el asistente completo, porque buscar, redactar, actualizar, enviar, eliminar y aprobar requieren información y autoridad diferentes. Verbos amplios como «ayudar» o «gestionar» ocultan esas diferencias. Conviene reemplazarlos por resultados observables: consultar un expediente elegible, resumirlo, crear un borrador no final o presentar una acción para aprobación. Esta descomposición es una síntesis editorial basada en principios de NIST y OWASP, no una exigencia formal de esas organizaciones.

• Nombre a los usuarios elegibles y establezca cómo se comprobará su identidad.
• Separe las tareas admitidas de las decisiones que siempre quedarán fuera del servicio.
• Defina el resultado permitido, la supervisión y el dueño de cada riesgo antes de habilitar una herramienta.
• Evite una capacidad genérica cuando varias operaciones estrechas puedan revisarse y retirarse por separado.

¿Qué información puede usar cada capacidad?

Cada capacidad debe operar dentro de un sobre de información definido, no simplemente dentro de la ventana técnica del modelo. Un límite de contexto debe definir fuentes, registros, vigencia, nivel de confianza, historial de sesión, memoria persistente y datos prohibidos, además del presupuesto técnico de tokens. También debe respetar los permisos del usuario, los filtros por cuenta u objeto, la clasificación de la información y el periodo relevante para la tarea. Una ventana mayor no crea autoridad ni convierte evidencia insuficiente en un hecho.

Los mensajes externos, adjuntos, documentos recuperados y respuestas de API deben ingresar como contenido no confiable, separado de las instrucciones del servicio. Un texto encontrado en un expediente puede aportar evidencia, pero no debe modificar silenciosamente la política ni ordenar una herramienta. La memoria persistente requiere reglas distintas del historial de la conversación: qué puede guardarse, cómo se valida, cómo se aísla por usuario y sesión, cuándo vence, cómo se elimina y qué información nunca debe persistir.

• Rechace la consulta si exige información que el usuario o la capacidad no pueden usar.
• Califique la respuesta cuando la evidencia requerida esté incompleta, desactualizada o fuera del periodo aprobado.
• Defina límites de tamaño y vencimiento según el servicio, sin adoptar cifras universales.
• Mantenga credenciales, secretos y datos prohibidos fuera del prompt, la memoria y los registros.

¿Cómo deben aplicarse la identidad, las herramientas y los permisos?

La identidad, la autorización y la aprobación deben evaluarse por separado y aplicarse fuera del modelo. La autenticación establece quién actúa; la autorización permite una operación sobre un recurso protegido; y la aprobación acepta una acción propuesta en particular. El diseño debe elegir expresamente entre autoridad delegada por el usuario y una identidad de carga de trabajo controlada. Nunca debe heredar en silencio la sesión privilegiada de un operador ni usar una credencial amplia solo porque facilita la integración.

Los permisos de herramientas y recursos deben aplicarse en la pasarela y en el sistema de destino sobre la identidad actuante, no quedar a criterio del modelo o de su prompt. Exponga operaciones como «leer caso elegible» o «crear borrador» en lugar de acceso general al correo, la base de datos, el navegador o una consola. Las operaciones estrechas y los permisos mínimos reducen el conjunto de acciones no deseadas frente a herramientas abiertas o accesos indiscriminados, aunque no eliminan errores, filtraciones ni instrucciones maliciosas.

• Restrinja verbos, recursos, objetos, campos, destinos y duración de la credencial.
• Valide parámetros y audiencia del token en la ruta de ejecución.
• Use alcances incrementales cuando una integración protegida lo permita.
• Aplique límites propios del servicio para reintentos, cadenas, lotes, gasto, tiempo y circuitos de detención.

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

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

Cada capacidad necesita un tope de acción explícito, reforzado a medida que se acerca a un efecto externo. Una escala editorial práctica distingue entre responder o resumir, recomendar, preparar una propuesta, crear un borrador, realizar una escritura reversible y ejecutar una acción consecuente. El último nivel corresponde a decisiones prohibidas que el servicio no debe tomar. La escala no es un estándar de NIST u OWASP; sirve para convertir sus principios de restricción, mediación y falla segura en decisiones operativas revisables.

1. Responder o resumir información elegible sin modificar un sistema externo.
2. Recomendar o presentar una propuesta inspeccionable sin ejecutarla.
3. Crear un artefacto editable en estado no final y con revisor asignado.
4. Modificar campos autorizados dentro de un flujo reversible y auditable.
5. Ejecutar una acción externa solo con autorización vigente, aprobación exacta y política independiente.
6. Denegar una decisión excluida y derivarla a un proceso gobernado por especialistas.

Para una acción consecuente, la aprobación debe vincularse al actor, la herramienta, el recurso objetivo, los parámetros normalizados, el momento y el vencimiento, y validarse antes de ejecutar. La vista previa debe mostrar qué se enviará, publicará o modificará. Si cambia el destinatario, el contenido o cualquier parámetro material, se necesita una validación nueva. La aprobación no concede un permiso ausente ni convierte una decisión prohibida en una acción válida. Pagos, accesos, cambios destructivos, producción y compromisos materiales necesitan control humano calificado y políticas deterministas apropiadas.

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

La negativa, la ayuda parcial, la derivación humana y la escalación de seguridad deben diseñarse como resultados normales del servicio, con condiciones reales de detención. Un asistente acotado debe negarse cuando la tarea, los datos, la acción o la autoridad estén fuera de la capacidad declarada, y ofrecer solo ayuda parcial segura o una derivación responsable. Debe explicar el límite en lenguaje sencillo, sin revelar reglas sensibles y sin afirmar que una consulta, aprobación o escritura tuvo éxito cuando falló.

• Tarea fuera de alcance o información no elegible.
• Autorización insuficiente o aprobación pendiente.
• Evidencia ausente, inaccesible o desactualizada.
• Juicio especializado, política o decisión responsable requerida.
• Dependencia no disponible o límite operativo alcanzado.
• Señal de seguridad, posible exfiltración, escalamiento de privilegios o abuso recursivo.

La derivación debe incluir el objetivo original, el contexto no sensible relevante, la capacidad intentada, el motivo de la detención, la evidencia disponible o faltante, el siguiente paso propuesto y un identificador de trazabilidad. El trabajo queda detenido mientras actúa el responsable correspondiente. Una consulta cotidiana para completar datos, una aprobación comercial y un incidente de seguridad pueden compartir evidencia, pero tienen distintos dueños y urgencias. Si la acción propuesta cambia durante la revisión, no debe reanudarse con una aprobación antigua.

¿Cómo convertir los 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 un responsable. La fila debe registrar actor elegible, autenticación, sobre de información, sesión, memoria, herramienta estrecha, identidad actuante, recursos permitidos, tope de acción, aprobación, límites operativos, negativa, trazabilidad, escenarios de evaluación y destino de la escalación. Una fila como «el asistente accede al CRM» es demasiado amplia para decidir permisos o demostrar que una denegación funciona.

El registro debe permitir reconstruir quién pidió qué, qué capacidad y política se aplicaron, qué clases de fuentes y herramientas intervinieron, qué decisiones de autorización y aprobación ocurrieron y cuál fue el resultado, sin conservar secretos ni contexto sensible ilimitado. Los identificadores de versiones, recursos y acciones permiten investigar una ejecución sin depender del relato del asistente. La conservación y el acceso a esos datos deben ajustarse a las reglas internas de privacidad, seguridad y gestión documental.

¿Qué evidencia permite lanzar y mantener el asistente?

El lanzamiento requiere evidencia de que la capacidad presta el servicio permitido y también deniega, detiene o deriva correctamente en condiciones parecidas a las reales. La evaluación debe cubrir tareas permitidas y denegaciones esperadas, incluidos accesos entre cuentas, herramientas no autorizadas, contexto vencido o contaminado, evasión de aprobación, exfiltración y cadenas descontroladas. También debe probar parámetros modificados, reintentos duplicados, dependencias caídas y datos prohibidos. Un resultado satisfactorio describe el alcance probado; no garantiza el comportamiento futuro.

• Observe herramientas inesperadas, denegaciones repetidas, fallas de autorización y cambios de aprobación.
• Controle secuencias anómalas, latencia, consumo, errores y señales de deriva según el riesgo del servicio.
• Asigne responsables distintos para comportamiento, permisos, derivaciones comerciales e incidentes.
• Otorgue a esos responsables autoridad para pausar, revisar o retirar una capacidad.
• Comunique a usuarios y operadores las limitaciones y fallas conocidas.

Los cambios en modelos, prompts, herramientas, recuperación, memoria, políticas, permisos, datos o proveedores pueden modificar el comportamiento y deben reabrir las evaluaciones afectadas. La revisión debe abarcar también el contexto operativo cuando cambian los usuarios, las fuentes o el impacto posible. Conviene empezar con la capacidad útil más pequeña y ampliar autoridad mediante cambios revisados, no mediante retoques aislados del prompt. Si hay información sensible, memoria persistente, acceso privilegiado, compromisos externos o incidentes, deben participar los responsables de seguridad, identidad, privacidad, registros, riesgo y servicio.