Información clara y basada en fuentes sobre programas empresariales de IA.
Método práctico para delimitar capacidades, datos, herramientas, permisos, aprobaciones, rechazos, pruebas y escalados de un asistente de IA.
ModelFold Editorial Team10 min de lectura
El límite real de un asistente de IA es el contrato de servicio que puede ejecutar, no una prohibición escrita en sus instrucciones. Si dispone de una herramienta de envío y de una credencial válida, decirle que «no envíe» no constituye un control de autorización. El diseño debe dividir la experiencia conversacional en capacidades visibles —buscar, resumir, proponer, redactar, actualizar o enviar— y asignar a cada una su propio perímetro de información, identidad, permiso, techo de actuación, prueba, registro y responsable.
Ideas clave
El equipo debe empezar con una carta de servicio de una sola frase y convertirla después en operaciones concretas. Una fórmula útil es: «Para [usuarios elegibles], el asistente puede [familia de tareas] utilizando [información aprobada] para producir [resultado permitido], pero no puede [objetivos excluidos o decisiones consecuentes]». Antes de conectar herramientas, conviene fijar usuarios, entorno, tareas admitidas, límites de conocimiento, supervisión humana, propietario del riesgo y resultados prohibidos.
Verbos como «ayudar» o «gestionar» ocultan demasiadas decisiones. «Buscar un expediente visible», «resumirlo», «preparar una respuesta» y «enviarla» son servicios distintos, aunque aparezcan en la misma conversación. NIST respalda la documentación del propósito, el alcance, las tareas, los límites y la supervisión; OWASP aconseja ofrecer la mínima funcionalidad necesaria. La división por capacidades es una síntesis editorial práctica basada en esos principios, no una obligación formal impuesta por dichas organizaciones.
Cada capacidad debe tener un perímetro de información que defina qué datos son elegibles y dónde cambian los límites de confianza; no basta con fijar un número de tokens. Ese perímetro debe indicar sistemas aprobados, tipos y clasificaciones de registros, filtros de objeto, intervalos temporales, requisitos de vigencia, derechos del usuario y datos excluidos. Si faltan pruebas accesibles o están obsoletas, la respuesta debe rechazarse o expresar claramente su limitación.
Los mensajes externos, adjuntos, documentos recuperados y respuestas de API son contenido no fiable: pueden aportar datos, pero no convertirse silenciosamente en instrucciones del servicio. El historial de sesión y la memoria persistente requieren reglas separadas. Hay que decidir qué puede guardarse, cómo se aísla por usuario y sesión, qué se valida antes de persistir, cuándo caduca, cómo se borra y qué información nunca entra en memoria. Una ventana mayor no crea autoridad ni convierte una afirmación sin respaldo en verdadera.
La pasarela de herramientas y los sistemas de destino deben imponer los límites sobre una identidad actuante; el modelo no puede concederse permiso a sí mismo. El diseño separa tres preguntas: quién o qué está autenticado, qué operación sobre qué recurso está autorizada y si se ha aprobado una propuesta concreta. También debe elegir expresamente entre autoridad delegada del usuario y una identidad de carga de trabajo controlada, sin heredar de forma silenciosa la cuenta privilegiada de un operador.
Exponga operaciones estrechas con parámetros validados en vez de acceso general al correo, la base de datos, el navegador o el intérprete de comandos. Restrinja verbos, recursos, objetos, campos, destinos, duración de credenciales y audiencia de tokens en la ruta de ejecución. En integraciones MCP protegidas, la especificación separa clientes, recursos y servidores de autorización, y recomienda ámbitos mínimos y tokens ligados al recurso; ese diseño no es una norma universal para cualquier arquitectura.
La conversación puede ser continua; su autoridad debe dividirse en capacidades pequeñas e impuestas por separado.
Cada operación necesita un techo de actuación explícito, con controles independientes más fuertes conforme pasa de informar a modificar el mundo exterior. Una escala editorial útil distingue responder o resumir, recomendar, crear un borrador, efectuar una escritura acotada y reversible, causar una acción externa consecuente y encontrar una decisión prohibida. Esta escala traduce principios de mínimo privilegio y restricción de acciones; no es un nivel de riesgo universal definido por NIST, NCSC u OWASP.
Crear un borrador no debe implicar enviarlo, y proponer una modificación no equivale a aprobarla. Antes de una acción consecuente, el usuario necesita una vista previa inspeccionable. La aprobación debe quedar ligada al actor, la herramienta, el recurso de destino, los parámetros normalizados y una vigencia concreta, y volver a validarse al ejecutar. Si cambia el destinatario o el contenido, la propuesta anterior deja de ser la acción aprobada. Además, aprobar nunca amplía la autorización permanente.
Pagos, concesiones de acceso, borrados, cambios en producción, compromisos externos materiales y juicios profesionales de alto impacto deben permanecer bajo el control humano cualificado y las políticas deterministas que correspondan a la organización. La intervención humana tampoco compensa una credencial excesiva: debe revisar una propuesta concreta dentro de permisos ya válidos. El nivel adecuado depende del impacto, la reversibilidad, la identidad, el recurso afectado y las obligaciones internas, no de un umbral genérico de confianza del modelo.
El rechazo, la ayuda parcial, el traspaso humano y el escalado de seguridad deben ser resultados explícitos del servicio, con condiciones reales de parada. El asistente ha de explicar el límite en lenguaje claro sin revelar detalles sensibles y nunca fingir que una fuente, aprobación, llamada o escritura funcionó. Puede ofrecer únicamente la parte segura: pedir información ausente, preparar una lista de comprobación o dejar un borrador pendiente. NIST incluye el fallo seguro más allá de los límites documentados entre sus resultados de evaluación.
Un traspaso útil conserva el objetivo original, el contexto no sensible relevante, la capacidad intentada, el motivo, la evidencia disponible o ausente, el siguiente paso y un identificador de seguimiento. El destino depende del caso: la atención ordinaria corresponde al equipo de servicio; una aprobación empresarial, al responsable de la decisión; y una señal de escalada de privilegios, exfiltración, envenenamiento de memoria o abuso recursivo, al circuito de seguridad. La ejecución permanece detenida y cualquier cambio exige validación nueva.
El equipo debe completar una fila del lienzo de diseño por cada operación visible y conectar cada fila con controles aplicables, registros, pruebas, métricas y una persona responsable. Anote el actor, la autenticación, el perímetro de información, las reglas de sesión y memoria, la herramienta estrecha, la identidad actuante, el recurso, el techo de actuación, la aprobación, los límites operativos, el rechazo, las evidencias y el escalado. Un documento sin correspondencia con la ejecución y la observabilidad no controla el servicio.
Pensemos en un asistente interno que ayuda al personal de soporte a consultar casos y preparar respuestas. La misma conversación puede ofrecer un resumen, un borrador y un envío aprobado, pero las tres capacidades conservan accesos, herramientas y propietarios diferentes. Los registros deben reconstruir solicitud, capacidad, fuentes, política, autorización, aprobación y resultado mediante identificadores estructurados, ocultando secretos y evitando almacenar contexto sensible sin una necesidad operativa aprobada.
| Capacidad | Límite de información y herramienta | Techo de actuación y aprobación | Evidencias, pruebas, métricas y responsable |
|---|---|---|---|
| Resumir un caso elegible | Identidad delegada; lectura únicamente de casos ya visibles, limitada a la cuenta indicada; sin notas administrativas ocultas. | Responder o resumir, sin modificar registros. | Registrar casos y fuentes consultados y denegaciones. Probar cruces de cuenta, notas ocultas, datos obsoletos e instrucciones adversarias. El responsable del servicio investiga excepciones. |
| Crear un borrador de respuesta | Caso elegible, artículos aprobados y política de respuesta; escritura solo en un espacio de borradores, sin herramienta de envío. | Crear un borrador revisable; omitir compromisos sin respaldo y derivar el juicio pendiente. | Registrar fuentes, versión de política, borrador y revisión. Probar respaldo ausente, promesas no autorizadas, datos sensibles e instrucciones recuperadas. Responde el propietario de contenido o política. |
| Enviar una respuesta aprobada | Operación de envío independiente; identidad autorizada para el canal y el destinatario previstos; credencial ligada al recurso de mensajería. | Acción externa consecuente; validar autorización, destinatario, referencia de contenido, caducidad de aprobación y prevención de duplicados. | Registrar emisor, destino, aprobación y resultado. Probar cambios de parámetros, caducidad, reintentos y caída del canal. Responde el propietario de mensajería; la decisión empresarial sigue siendo humana. |
Las métricas también deben respetar la separación. En la consulta interesan los resultados de recuperación elegible y las denegaciones de perímetro; en el borrador, las marcas de afirmaciones sin respaldo y la decisión del revisor; en el envío, los resultados de ejecución y las denegaciones por discrepancia. NIST respalda funciones claras, responsabilidades diferenciadas, seguimiento y revisión periódica. La tabla es un método editorial para convertir esos principios y las recomendaciones de mínimo privilegio de OWASP en decisiones operativas.
El lanzamiento requiere evidencias de que el servicio permitido funciona y de que las denegaciones previstas se producen en condiciones semejantes al despliegue. Junto a las tareas positivas, pruebe accesos entre cuentas, herramientas no autorizadas, evidencia obsoleta, contenido recuperado manipulado, datos prohibidos, elusión de aprobación, parámetros cambiados, reintentos duplicados, fallos de dependencias, intentos de exfiltración y cadenas descontroladas. Las limitaciones y los modos de fallo conocidos deben quedar visibles para operadores y usuarios.
Los registros deben permitir reconstruir quién pidió qué, qué capacidad y versión de política se aplicaron, qué clases de fuentes y herramientas participaron, qué decisiones de autorización y aprobación se tomaron y qué resultado se produjo. No deben convertirse en un almacén indiscriminado de secretos o conversaciones sensibles. El seguimiento puede observar uso inesperado de herramientas, denegaciones repetidas, fallos de autorización, cambios de aprobación, secuencias anómalas, deriva, latencia, consumo y fallos, según las exigencias de riesgo y privacidad.
Un cambio material en el modelo, las instrucciones, la recuperación, la memoria, las herramientas, los permisos, las políticas, los datos, el proveedor o el contexto operativo debe reabrir las pruebas afectadas y la decisión de lanzamiento. Empiece por la capacidad útil más pequeña y amplíe su autoridad mediante cambios revisados, no mediante retoques aislados del prompt. Cuando intervengan datos sensibles, memoria persistente, acceso privilegiado, borrados o compromisos externos, incorpore a los responsables de seguridad, identidad, privacidad, riesgos, gestión documental y servicio; reserve los juicios especializados para profesionales cualificados y procesos separados.
Es un servicio empresarial cuyas tareas, datos, identidades, herramientas, actuaciones, rechazos y responsables están limitados de forma explícita. Esos límites se aplican en componentes externos al modelo, como la pasarela de herramientas, el sistema de identidad y el recurso de destino. El prompt explica el comportamiento esperado, pero no concede ni revoca permisos.
Cree una fila por cada capacidad visible, como leer un caso, redactar una respuesta o enviarla. Registre actor, autenticación, datos, operación, identidad actuante, recursos, techo de actuación, aprobación y límites. Añada los eventos de registro, escenarios de prueba, métricas, condiciones de parada y responsable de cada fila.
Debe limitar las fuentes y registros elegibles, los derechos del usuario, los filtros de objeto y fecha, la vigencia y la clase de confianza. Defina aparte el historial de sesión y la memoria persistente, con aislamiento, validación, caducidad, tamaño y borrado adecuados al servicio. Identifique también los datos que nunca pueden almacenarse.
No. La aprobación acepta una propuesta concreta, pero no sustituye la autorización en el sistema de destino ni corrige permisos permanentes excesivos. Tampoco convierte una decisión prohibida en permitida. Si cambian el actor, el destino o los parámetros, la acción debe validarse y aprobarse de nuevo.
Debe detenerse cuando la tarea quede fuera de alcance, los datos no sean elegibles, falte autoridad o aprobación, la evidencia sea insuficiente u obsoleta, se necesite juicio especializado, falle una dependencia, se alcance un límite operativo o aparezca una señal de seguridad. Puede ofrecer ayuda parcial segura y enviar al responsable un paquete de contexto no sensible y evidencias. El trabajo no se reanuda mientras la condición siga pendiente.
Para investigar este artículo se utilizaron 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 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 separe fuentes, pruebas y prosa, asigne revisiones claras y registre los cambios relevantes.
Método práctico para convertir un flujo empresarial acotado en un conjunto de evaluación reproducible, puntuable y útil para decidir lanzamientos.
Guía práctica para inventariar usos de IA, valorar su exposición con cuatro dimensiones y dirigir cada caso a una revisión proporcionada y mantenible.
