Información clara y basada en fuentes para programas de IA responsables.
Guía práctica para delimitar capacidades, datos, herramientas, permisos, aprobaciones, negativas, pruebas y responsables de un asistente de IA.
ModelFold Editorial Team11 min de lectura
El límite real de un asistente de IA es el contrato ejecutable que rodea al modelo: qué información recibe, con qué identidad actúa, qué herramientas puede invocar y qué sistemas rechazan una operación indebida. Una instrucción como “no envíes mensajes” no basta si el servicio conserva una credencial y una función capaces de enviarlos. Autorizar al asistente como un solo producto también mezcla tareas que merecen controles distintos. Buscar un expediente, resumirlo, preparar una respuesta y enviarla pueden sentirse como una conversación continua, pero no deben compartir automáticamente datos, permisos ni capacidad de acción.
Principios para fijar el límite
El equipo debe comenzar con una carta de servicio de una sola oración y convertirla en capacidades observables. 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 [objetivos excluidos o decisiones de consecuencias importantes]”. El núcleo del AI RMF de NIST pide documentar el propósito previsto, el entorno de despliegue, las tareas admitidas, los límites de conocimiento, el alcance, la supervisión humana y la tolerancia al riesgo. La fórmula es una síntesis editorial práctica, no un requisito de NIST.
Después hay que sustituir verbos amplios como “ayudar”, “gestionar” o “resolver” por operaciones separadas. Buscar, resumir, recomendar, redactar, actualizar, enviar, borrar y aprobar requieren sobres de información y autoridades diferentes. OWASP recomienda exponer la funcionalidad mínima de cada herramienta y preferir una operación estrecha frente a una extensión abierta. Antes de conectar cualquier sistema, conviene dejar explícitos los usuarios admitidos, el canal de uso, las tareas respaldadas, la supervisión, el dueño del riesgo y los resultados prohibidos.
Cada capacidad necesita un sobre de información: una definición de los datos elegibles y de las fronteras de confianza, no sólo un presupuesto de tokens. Debe precisar sistemas aprobados, tipos de registro, clasificaciones, cuentas u objetos permitidos, campos, fechas, vigencia esperada, derechos del usuario y datos prohibidos. Los resultados de Map de NIST contemplan límites de conocimiento documentados, un alcance de aplicación definido y supervisión sobre el uso de las salidas. Una ventana de contexto más grande no amplía la autoridad ni convierte evidencia ausente en información verdadera.
También debe distinguirse el contenido de las instrucciones. OWASP aconseja tratar mensajes externos, documentos, respuestas de API y contenido recuperado como información no confiable, separada de las instrucciones del servicio. Para la memoria persistente, la guía de memoria de OWASP abarca validación previa a la persistencia, aislamiento por usuario y sesión, caducidad, límites de tamaño, revisión de datos sensibles y protección de integridad. El historial de una conversación y la memoria duradera requieren reglas distintas de elegibilidad, eliminación y aislamiento; ninguno debe convertirse en un depósito automático.
La autenticación, la autorización y la aprobación deben resolverse por separado, mientras la puerta de herramientas y el sistema de destino hacen cumplir el límite. La autenticación responde quién es el usuario, cliente o carga de trabajo; la autorización, qué operación puede realizar sobre cuál recurso; la aprobación, si una propuesta concreta fue aceptada. La especificación de autorización de MCP distingue servidores de recursos protegidos, clientes que actúan por propietarios de recursos y servidores que emiten tokens. Para servidores MCP protegidos, recomienda alcances de mínimo privilegio y permite ligar la autorización al servidor de recursos previsto; esto no es una regla universal para toda arquitectura.
El diseño debe escoger de forma expresa entre autoridad delegada del usuario y una identidad de carga de trabajo controlada. Nunca debe heredar silenciosamente la cuenta privilegiada de quien configuró el servicio. OWASP recomienda permisos posteriores mínimos, conservar el contexto de autorización del usuario y mediar cada solicitud en el sistema de destino. También aconseja ligar la aprobación de una acción de alto impacto al actor, la herramienta, el recurso, los parámetros normalizados, el momento y la caducidad. El NCSC recomienda mínimo privilegio, configuraciones seguras, restricciones de acción y salvaguardas externas cuando un componente de IA puede activar operaciones.
La conversación puede ser continua; la autoridad debe estar dividida en capacidades pequeñas y aplicadas de manera independiente.
Toda capacidad necesita un techo de acción explícito, con controles independientes más fuertes conforme pasa de informar a modificar el mundo externo. Una escala práctica distingue entre responder o resumir; recomendar o proponer; crear un borrador; realizar una escritura acotada y reversible; provocar una acción externa de consecuencias importantes; y encontrar una decisión prohibida. Esta escala es síntesis editorial apoyada en principios de control, no una jerarquía impuesta por NIST, OWASP o el NCSC. El borrador debe permanecer separado del envío, y una propuesta no debe confundirse con una decisión responsable.
OWASP aconseja separar la decisión de la ejecución en acciones de alto impacto y validar una aprobación vinculada a la propuesta concreta. También recomienda aprobación humana antes de acciones de alto impacto y, por separado, autorización mediada por el sistema de destino. Aprobar nunca concede un permiso faltante, amplía la autorización permanente ni vuelve admisible una decisión prohibida. El NCSC recomienda restringir las acciones que puede activar un componente de IA y utilizar salvaguardas externas cuando corresponda. Pagos, altas de acceso, borrados, cambios productivos, compromisos materiales y juicios profesionales de alto impacto requieren control humano calificado y políticas deterministas apropiadas.
La negativa, la ayuda parcial segura, la transferencia humana y el escalamiento de seguridad deben diseñarse como resultados explícitos del servicio, con condiciones reales de paro. Los resultados de Measure de NIST incluyen evaluar en condiciones parecidas al despliegue y fallar de forma segura más allá de los límites de conocimiento documentados. El asistente debe explicar el límite en lenguaje sencillo sin revelar reglas sensibles ni afirmar que una consulta, aprobación, llamada o escritura tuvo éxito cuando no ocurrió. Si puede completar una parte segura, debe ofrecerla sin continuar la acción bloqueada.
La transferencia debe incluir el objetivo original, contexto no sensible, capacidad intentada, motivo, evidencia disponible o faltante, siguiente paso y un identificador de trazabilidad. Deben conservarse rutas distintas para atención rutinaria, aprobación de negocio e incidente de seguridad, pues tienen responsables y urgencias diferentes. El NCSC recomienda planes de incidentes con escenarios de respuesta, escalamiento y remediación, personal preparado y registros de auditoría de calidad. OWASP identifica eludir aprobaciones, escalar privilegios, extraer datos, envenenar memoria y abusar de llamadas recursivas entre los casos que debe considerar el diseño. Si cambia la acción propuesta, se exige una nueva validación.
El equipo debe completar una fila de diseño por cada operación visible para el usuario y conectar cada campo con controles, evidencia, pruebas, métricas y un responsable. La fila debe registrar actor elegible, autenticación, sobre de información, sesión y memoria, herramienta estrecha, identidad actuante, recursos permitidos, techo de acción, aprobación, límites operativos, negativa, evidencia, escenarios de evaluación, señales de producción y dueño. La recomendación de OWASP de minimizar funciones y permisos respalda separar los controles de lectura, borrador y envío. El lienzo es una síntesis editorial; no sirve si queda como documentación sin ejecución.
Para hacerlo concreto, pensemos en un asistente interno que ayuda al personal de soporte a consultar casos y preparar respuestas. Resumir un caso, redactar una respuesta y enviarla pueden compartir interfaz, pero deben conservar accesos, herramientas y techos separados. La guía de OWASP contempla registrar decisiones, llamadas a herramientas, resultados de autorización, identificadores de aprobación, versiones de política, resultados y uso de recursos, con datos sensibles redactados. Los resultados de gobernanza de NIST piden funciones claras, líneas de comunicación, responsabilidades humanas y de IA diferenciadas, monitoreo continuo y revisión periódica.
| Capacidad | Límite de información y herramienta | Techo de acción y aprobación | Evidencia, pruebas, métricas y responsable |
|---|---|---|---|
| Buscar y resumir un caso elegible | Identidad delegada; lectura sólo de casos ya visibles para la persona; cuenta nombrada y registros pertinentes; sin notas administrativas ocultas. | Responder o resumir, sin escribir ni enviar. | Registrar política, casos y fuentes; probar cruces de cuenta, evidencia desactualizada, notas ocultas e instrucciones adversariales; medir recuperaciones elegibles y negativas; responde el dueño del servicio. |
| Crear un borrador de respuesta | Caso elegible, artículos aprobados y política de respuesta; escritura únicamente en un espacio de borradores; sin permiso de envío. | Crear un borrador editable; compromisos sin respaldo se omiten y se remiten a revisión. | Registrar fuentes, versiones, marcador de afirmaciones sin apoyo y disposición del revisor; probar promesas no autorizadas, datos sensibles y texto recuperado adversarial; responde el dueño de contenido o política. |
| Enviar una respuesta aprobada | Operación de envío independiente; identidad autorizada sólo para el canal y destinatario previstos; credencial ligada al recurso de mensajería. | Acción externa con destinatario, contenido y aprobación vigentes; negar si cambian los parámetros o falta autorización. | Registrar destinatario, referencia de contenido, identidad, aprobación, resultado y clave contra duplicados; probar cambios, caducidad, reintentos y caída del canal; responde el dueño de mensajería y aprueba la persona remitente. |
La liberación requiere evidencia de que el servicio permitido funciona y de que las negativas esperadas se mantienen en condiciones parecidas al despliegue. El AI RMF de NIST contempla pruebas representativas del despliegue, monitoreo en producción, límites documentados, falla segura y evaluaciones periódicas de seguridad. El NCSC recomienda evaluar la seguridad antes de liberar un sistema y comunicar las limitaciones y modalidades de falla conocidas. Una prueba aprobada no es garantía permanente: cada escenario debe estar ligado a la capacidad, política, herramienta y versión que realmente llegarán a producción.
Los registros deben permitir reconstruir quién pidió qué, cuál capacidad y política aplicaron, qué clases de fuente y herramienta participaron, qué decisiones de autorización y aprobación ocurrieron, qué resultado se produjo y qué versiones estaban activas. No deben guardar secretos ni contexto sensible sin límite. El NCSC recomienda monitorear salidas y desempeño para observar cambios de seguridad repentinos o graduales, respetando los requisitos de privacidad y protección de datos. Las señales útiles incluyen herramientas inesperadas, negativas repetidas, fallas de autorización, cambios de aprobación, secuencias anómalas, latencia, consumo y fallas por capacidad.
Cada capacidad necesita responsables diferenciados para comportamiento del servicio, concesiones de acceso, transferencias de negocio e incidentes, además de autoridad para pausar, corregir o retirar la operación. El NCSC señala que modificar datos, modelos o instrucciones puede cambiar el comportamiento y debe reflejarse en las pruebas y evaluaciones. El mismo principio debe aplicarse, de forma proporcional, a cambios materiales en recuperación, memoria, herramientas, permisos, políticas, proveedores o contexto operativo. Conviene empezar por la capacidad útil más pequeña y ampliar autoridad mediante cambios revisados, no mediante una modificación aislada de la instrucción del modelo.
Es un servicio empresarial cuyas tareas, datos, identidades, herramientas, acciones, pruebas, negativas y responsabilidades están limitados de manera explícita. Sus fronteras se aplican en puertas de herramientas y sistemas de destino, no sólo en las instrucciones del modelo. Cuando una solicitud rebasa esas fronteras, el servicio se detiene, ofrece ayuda parcial segura o la dirige al responsable adecuado.
Se crea una fila por cada capacidad visible, como leer un caso, preparar un borrador o enviar una respuesta. En cada fila se documentan actor, autenticación, datos, herramienta, identidad actuante, recursos, techo de acción, aprobación, límites, registros, pruebas, métricas y responsable. Las filas deben corresponder a controles ejecutables, no limitarse a describir que el asistente “tiene acceso” a un sistema.
Debe limitar fuentes, registros, clasificaciones, cuentas, campos, fechas, vigencia, derechos del usuario y clases de confianza. El historial de sesión y la memoria persistente necesitan reglas separadas de aislamiento, validación, tamaño, caducidad y eliminación, además de datos que nunca deben conservarse. Los valores concretos dependen del servicio; una ventana más grande no concede autoridad ni corrige evidencia insuficiente.
No. La aprobación acepta una propuesta específica, pero no sustituye la autorización en el sistema de destino ni reduce permisos permanentes excesivos. Tampoco convierte una decisión prohibida en permitida. Para acciones de consecuencias importantes, la ejecución debe volver a validar identidad, recurso, parámetros, vigencia, autorización y aprobación antes de producir el efecto externo.
Debe negarse cuando la tarea esté fuera de alcance, la información no sea elegible, falte autoridad o aprobación, la evidencia sea insuficiente, se requiera juicio especializado, falle una dependencia, se alcance un límite operativo o aparezca una señal de seguridad. Puede ofrecer una parte segura, como un borrador o una solicitud de información. La transferencia debe incluir contexto no sensible, motivo, evidencia, siguiente paso y trazabilidad, mientras la ejecución permanece detenida.
Este artículo se investigó con las siguientes fuentes:
Contamos cómo aterriza realmente la IA dentro de una empresa. Trabajamos a partir de fuentes identificadas, separamos lo que encontramos de lo que opinamos y usamos apoyo de IA para investigar y redactar bajo controles editoriales documentados. No sustituimos la revisión de un experto.
Diseña un flujo de redacción con IA generativa que separa fuentes, evidencia y prosa, asigna revisiones claras y registra cambios importantes.
Método práctico para convertir un flujo empresarial acotado en escenarios reproducibles, con criterios válidos y evidencia protegida para lanzamientos.
Diseña un inventario mantenible de usos de IA, clasifica su exposición en cuatro dimensiones y asigna revisiones proporcionales sin confundir obligaciones.
