Información práctica y basada en fuentes para programas de IA responsables.
Método práctico para acotar un asistente de IA mediante capacidades, contexto, permisos, aprobaciones, pruebas, registros y escalamiento responsable.
ModelFold Editorial Team9 min de lectura
El límite real de un asistente de IA es el contrato ejecutable del servicio, no una prohibición escrita en su instrucción. Si el modelo recibe una herramienta para enviar mensajes y una credencial que permite usarla, pedirle que “no envíe” no revoca esa capacidad. El diseño debe separar lo que conversa de lo que puede leer, decidir y ejecutar. Así, una consulta cotidiana no hereda por accidente datos de otras cuentas, permisos de un operador privilegiado ni una ruta para producir efectos que nadie quiso autorizar.
Ideas clave
El equipo debe empezar con una carta de servicio de una sola oración y descomponerla en capacidades visibles y objetivos excluidos. Una fórmula útil es: “Para usuarios elegibles, el asistente puede realizar esta familia de tareas con esta información aprobada para producir este resultado, pero no puede tomar estas decisiones ni causar estos efectos”. Antes de conectar herramientas, conviene nombrar usuarios, entorno, tareas admitidas, límites de conocimiento, supervisión humana y responsable del riesgo.
Verbos como “ayudar” o “gestionar” esconden demasiada autoridad. Es mejor declarar operaciones separadas: buscar un caso, resumirlo, recomendar un paso, crear un borrador, actualizar campos permitidos, enviar una respuesta, borrar un registro o aprobar una acción. El AI RMF de NIST respalda la documentación del propósito, alcance, tareas, límites y supervisión; OWASP recomienda funciones mínimas. El método por capacidad es una síntesis editorial práctica, no una obligación impuesta por esas organizaciones.
Cada capacidad necesita un sobre de información que defina los datos elegibles y sus fronteras de confianza; no basta con fijar un presupuesto de tokens. La ficha debe identificar sistemas aprobados, tipos de registro, clasificaciones, filtros por objeto o cuenta, fechas, vigencia esperada, permisos del usuario y datos excluidos. Si la evidencia requerida no está disponible, está incompleta o perdió vigencia, el asistente debe negarse a concluir o expresar claramente la limitación.
Los documentos recuperados, mensajes externos, adjuntos y respuestas de interfaces deben tratarse como contenido no confiable y mantenerse separados de las instrucciones del servicio. La memoria persistente también requiere reglas propias: qué puede guardarse, cómo se valida, cómo se aíslan usuarios y sesiones, cuándo vence, cómo se elimina y qué nunca se conserva. Una ventana de contexto mayor no amplía la autorización ni convierte información sin respaldo en verdadera.
La autenticación, la autorización y la aprobación deben resolverse por separado, y la pasarela de herramientas y el sistema de destino deben imponer el límite. La autenticación establece quién actúa; la autorización determina qué operación puede realizar sobre qué recurso; la aprobación acepta una propuesta concreta. El servicio debe elegir entre autoridad delegada del usuario y una identidad de carga controlada, sin heredar silenciosamente la cuenta privilegiada de quien configuró la integración.
Exponga operaciones estrechas con parámetros validados, no acceso general al buzón, base de datos, navegador o terminal. En la ruta de ejecución deben limitarse verbos, recursos, objetos, campos, destinos, duración de credenciales y destinatario del token. OWASP recomienda permisos posteriores mínimos y mediación completa. Para servidores MCP protegidos, la especificación añade alcances de mínimo privilegio y vinculación al recurso previsto; esa implementación no es una regla universal para toda arquitectura.
La conversación puede sentirse continua, pero su autoridad debe dividirse en capacidades pequeñas y aplicadas por separado.
Cada capacidad debe tener un techo de acción explícito, con controles independientes más fuertes a medida que pasa de responder a modificar el estado externo. Esta escalera es una síntesis editorial: informar o resumir; recomendar; crear un borrador; realizar una escritura acotada y reversible; causar un efecto externo consecuente; o encontrarse con una decisión prohibida. Crear un borrador no equivale a enviarlo, y proponer una modificación no equivale a ejecutarla.
Para una acción consecuente, la aprobación debe quedar vinculada al actor, herramienta, recurso, parámetros normalizados, momento y vencimiento, y volver a validarse antes de ejecutar. Si cambia el destinatario, contenido o monto, la propuesta ya no es la aprobada. La aprobación jamás aporta una autorización ausente ni habilita una decisión prohibida. Pagos, concesión de accesos, operaciones destructivas, cambios productivos, compromisos externos y juicios profesionales de alto impacto requieren política determinista y control humano calificado.
La negativa, la ayuda parcial, la derivación humana y el escalamiento de seguridad deben diseñarse como resultados explícitos, con una parada real mientras actúa el responsable. El asistente debe explicar el límite sin revelar detalles sensibles y nunca afirmar que consultó una fuente, utilizó una herramienta, obtuvo aprobación o escribió un registro cuando no ocurrió. Puede ofrecer la parte segura: un borrador, una lista de verificación o una solicitud clara de información faltante.
La derivación debe llevar el objetivo original, contexto pertinente no sensible, capacidad intentada, motivo, evidencia disponible o faltante, próximo paso propuesto e identificador de trazabilidad. La atención rutinaria, la aprobación empresarial y un incidente de seguridad pueden compartir evidencia, pero tienen dueños y urgencias diferentes. Un cambio en la acción propuesta exige una validación nueva; no debe reanudarse silenciosamente una ejecución pendiente. NCSC recomienda planes de respuesta, escalamiento, remediación, personal preparado y registros de auditoría.
El equipo debe completar una fila del lienzo por cada operación visible y conectar esa fila con controles aplicables, evidencia, pruebas, métricas y un dueño. Registre actor, autenticación, sobre de información, sesión y memoria, herramienta estrecha, identidad actuante, alcance del recurso, techo de acción, aprobación, límites operativos, negativa, registro, escenarios y escalamiento. El lienzo es una síntesis práctica: si termina como documentación sin controles en la ejecución, no constituye el límite del servicio.
| Capacidad | Información y herramienta | Techo de acción y aprobación | Evidencia, pruebas, métricas y dueño |
|---|---|---|---|
| Buscar y resumir un caso elegible | Identidad delegada; lectura únicamente de casos ya visibles para el colaborador, limitada a la cuenta nombrada; excluye credenciales, otras cuentas y notas administrativas ocultas. | Solo responder o resumir. Niega registros ajenos, ocultos o sin evidencia vigente. | Registra capacidad, política, casos, fuentes, resultado y motivo de negativa. Prueba acceso cruzado, notas ocultas, evidencia vencida e instrucciones adversarias. El dueño del servicio investiga excepciones. |
| Crear un borrador de respuesta | Caso elegible, artículos aprobados y política de respuesta; escribe únicamente en un espacio de borradores y carece de permiso de envío. | Crea un artefacto no final. Omite compromisos sin respaldo y deriva el juicio faltante al revisor correspondiente. | Registra fuentes, versiones, borrador, alertas y disposición del revisor. Prueba políticas ausentes, promesas no autorizadas, datos sensibles y texto recuperado adversario. Responde el dueño de contenido o política. |
| Enviar una respuesta aprobada | Operación de envío separada; identidad autorizada solo para el canal y destinatario previstos; credencial vinculada al recurso de mensajería. | Acción externa consecuente. Valida destinatario, referencia del contenido, autorización, aprobación vigente y prevención de duplicados. | Registra remitente, destinatario, canal, aprobación, política y resultado. Prueba parámetros cambiados, aprobación vencida, autorización ausente, reintento duplicado y caída del canal. Responde el dueño de mensajería; aprueba el remitente humano. |
El lanzamiento requiere evidencia de que funcionan tanto el servicio permitido como las negativas previstas en condiciones parecidas al despliegue. No basta con probar respuestas correctas: deben ensayarse acceso entre cuentas, herramientas no autorizadas, evidencia vencida, contenido recuperado manipulado, datos prohibidos, evasión de aprobación, parámetros cambiados, reintentos duplicados, fallas de dependencias, intentos de exfiltración y cadenas descontroladas. NIST respalda pruebas representativas, monitoreo, límites documentados y fallas seguras.
En producción, observe 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 del servicio. Asigne dueños distintos para comportamiento, concesión de accesos, derivaciones comerciales e incidentes. NCSC indica que cambios en datos, modelos e instrucciones pueden alterar el comportamiento; por eso también deben reabrirse las pruebas afectadas cuando cambien recuperación, memoria, herramientas, permisos, políticas, proveedores o contexto operativo.
Empiece con la capacidad útil más pequeña y amplíe la autoridad mediante cambios revisados, no mediante una edición aislada de la instrucción. Consulte a los responsables de seguridad, identidad, privacidad, archivo, riesgo y servicio cuando haya información sensible, memoria persistente, acceso privilegiado, compromisos externos, cambios destructivos o respuesta a incidentes. Los juicios legales, regulatorios y demás decisiones profesionales de alto impacto deben permanecer con especialistas calificados y dentro de un proceso gobernado por separado.
Es un servicio empresarial cuyas tareas, información, identidades, herramientas, acciones y negativas están limitadas explícitamente. Esos límites se aplican fuera del modelo, se registran y tienen responsables definidos.
Cree una fila por cada capacidad visible, no una sola para todo el asistente. Registre actor, datos elegibles, operación, recurso, techo de acción, aprobación, límites, evidencia, pruebas, métricas y dueño.
Defina fuentes, registros, permisos del usuario, filtros, vigencia, clases de confianza e historial de sesión. Separe la memoria persistente y establezca elegibilidad, aislamiento, vencimiento, eliminación y datos que nunca deben guardarse.
No. La aprobación acepta una propuesta concreta, pero no reemplaza la autorización del sistema de destino, no reduce permisos permanentes excesivos y no vuelve permitida una decisión prohibida.
Debe detenerse cuando la tarea o los datos están fuera del alcance, falta autoridad o evidencia, se requiere un especialista, falla una dependencia, se alcanza un límite o aparece una señal de seguridad. Puede ofrecer ayuda parcial segura y derivar el caso con contexto no sensible y trazabilidad.
Este artículo se investigó utilizando las siguientes fuentes:
Contamos cómo aterriza realmente la IA dentro de una empresa. Partimos de fuentes identificadas, separamos lo que encontramos de lo que opinamos y usamos asistencia 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 delimita fuentes, separa evidencia y texto, asigna revisiones y conserva cambios decisivos.
Método práctico para convertir un flujo empresarial acotado en escenarios reproducibles, calificables y útiles para decidir una liberación.
Diseñe un inventario mantenible de usos de IA, clasifique su exposición con cuatro dimensiones y dirija cada caso a una revisión proporcional.
