Inteligencia práctica para programas de IA responsables.
Método práctico para acotar un asistente de IA por capacidades, datos, herramientas, permisos, aprobaciones, pruebas y rutas de escalamiento.
ModelFold Editorial Team10 min de lectura
El límite real de un asistente de IA es el contrato ejecutable que rodea al modelo, no una prohibición escrita en su instrucción. Si el servicio conserva una herramienta, una credencial y una ruta capaces de enviar un mensaje, la frase “no envíes” no constituye un control de autorización. El diseño debe dividir la conversación en capacidades pequeñas y aplicar a cada una datos elegibles, identidad, permisos, techo de acción, evidencia y una salida segura.
Decisiones clave
El equipo debería comenzar con una carta de servicio de una sola oración: “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 relevantes]”. Antes de conectar herramientas, esa frase obliga a precisar usuarios, entorno, tareas compatibles, límites de conocimiento, supervisión humana, responsable del riesgo y resultados expresamente prohibidos.
Luego hay que reemplazar verbos amplios como “ayudar” o “gestionar” por operaciones observables. Buscar un caso, resumirlo, recomendar un paso, crear un borrador, actualizar un campo, enviar una respuesta, eliminar un registro y aprobar una excepción no comparten el mismo riesgo. Esta separación por capacidad es una síntesis editorial práctica, informada por los resultados de NIST AI RMF y la recomendación de OWASP de exponer funcionalidad mínima; no es una arquitectura exigida literalmente por esas organizaciones.
Cada capacidad necesita un sobre de información: una definición de los datos elegibles y de sus fronteras de confianza, no solo un presupuesto de tokens. El sobre debería indicar sistemas aprobados, tipos de registro, clasificaciones, filtros por objeto, períodos pertinentes, expectativas de vigencia, permisos del usuario y datos excluidos. Si una fuente necesaria no está disponible, está desactualizada o queda fuera del permiso, el servicio debe negar o calificar la respuesta.
Los mensajes externos, documentos adjuntos, resultados de búsqueda y respuestas de API deben entrar como contenido no confiable, separados de las instrucciones que gobiernan el servicio. También conviene diseñar por separado el historial de la sesión y la memoria persistente: qué puede guardarse, cómo se aísla por usuario y sesión, qué validación exige, cuándo vence, cómo se elimina y qué información jamás se conserva. Una ventana de contexto mayor no entrega nueva autoridad ni vuelve verdadera una afirmación sin respaldo.
La autenticación, la autorización y la aprobación deben resolverse como decisiones separadas, mientras la pasarela de herramientas y los sistemas de destino aplican los límites. La autenticación establece quién es el usuario, cliente o servicio. La autorización decide si esa identidad puede ejecutar una operación sobre un recurso protegido. La aprobación acepta una propuesta concreta. El modelo puede interpretar la solicitud, pero ni su respuesta ni una regla en lenguaje natural reemplazan esos controles.
Para actuar, el equipo debe elegir expresamente entre autoridad delegada del usuario y una identidad de carga de trabajo controlada. No corresponde heredar silenciosamente la cuenta privilegiada de un operador. La herramienta debería ofrecer operaciones estrechas, con parámetros validados, en vez de acceso general a correo, bases de datos, navegador o consola. Verbos, recursos, objetos, campos, destinos, duración de credenciales y audiencia del token se restringen en la ruta de ejecución; en MCP protegido, los alcances y recursos vinculados ilustran esta separación, pero no prescriben todas las arquitecturas.
La conversación puede sentirse continua, pero su autoridad debe dividirse en capacidades pequeñas e independientemente exigibles.
Toda capacidad necesita un techo de acción explícito, con controles independientes más fuertes a medida que se acerca a modificar el estado externo. Una escala práctica distingue responder o resumir; recomendar o proponer; crear un borrador; realizar una escritura acotada y reversible; causar una acción externa relevante; y enfrentar una decisión prohibida. Es una síntesis editorial apoyada en principios de mínimo privilegio, aprobación y restricciones externas, no una clasificación universal de NIST, OWASP o NCSC.
Un borrador debe quedar separado del envío, una actualización reversible de una eliminación y una propuesta de la decisión responsable. Antes de una acción relevante, la persona aprobadora necesita una vista inspeccionable del efecto previsto. La aprobación debe quedar vinculada al actor, la herramienta, el recurso de destino, los parámetros normalizados, el momento y el vencimiento, y volver a validarse al ejecutar. No entrega permisos faltantes, no amplía la autorización permanente y no vuelve admisible una decisión prohibida.
El rechazo, la ayuda parcial segura, la derivación humana y el escalamiento de seguridad deben diseñarse como resultados explícitos del servicio, con una detención real de la ejecución. Las categorías pueden incluir tarea fuera de alcance, información no elegible, autorización insuficiente, aprobación pendiente, evidencia ausente u obsoleta, juicio especializado requerido, dependencia indisponible, límite operativo alcanzado o señal de seguridad. El mensaje debe explicar la frontera sin revelar detalles sensibles de la política.
El asistente nunca debería afirmar que verificó una fuente, llamó una herramienta, obtuvo una aprobación o realizó una escritura si aquello no ocurrió. Puede ofrecer la parte segura —por ejemplo, un borrador, una lista de verificación o una solicitud de datos faltantes— y preparar una entrega estructurada. Esa entrega reúne el objetivo original, contexto no sensible, capacidad intentada, razón, evidencia disponible o ausente, siguiente paso y un identificador de trazabilidad para el responsable correcto.
Los equipos pueden completar una fila de diseño por cada operación visible para el usuario y conectar cada fila con controles exigibles, evidencia, pruebas, métricas y una persona responsable. La ficha debería registrar actor elegible, autenticación, sobre de información, reglas de sesión y memoria, operación de herramienta, identidad actuante, alcance del recurso, techo de acción, aprobación, límites operativos, rechazo, registro, escenarios de evaluación, señales de producción y dueño con autoridad para modificar o retirar la capacidad.
Considere un asistente interno para personal de soporte de cuentas. La misma conversación puede permitir resumir un caso elegible, crear un borrador de respuesta y enviar una respuesta aprobada, pero las tres operaciones no deben compartir automáticamente datos, herramientas ni permisos. El servicio tampoco decide compensaciones, modifica derechos del cliente ni emite determinaciones regulatorias. La tabla aplica la ficha como síntesis editorial: convierte la documentación en decisiones comprobables y rutas de responsabilidad.
| 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 | Usa la identidad delegada del funcionario y lectura exclusiva de casos ya visibles para esa persona. Recupera la cuenta solicitada y excluye credenciales, otras cuentas y notas administrativas ocultas. | Solo responde o resume. Rechaza registros inaccesibles, evidencia obsoleta y respuestas sin respaldo; no modifica el caso. | Registra capacidad, política, identificadores del caso, clase del resultado y motivo de rechazo. Prueba cruces de cuenta, notas ocultas, adjuntos adversariales y falta de respaldo. El dueño del servicio investiga calidad de datos o señales de seguridad. |
| Crear un borrador de respuesta | Usa el caso elegible, artículos aprobados y la política de respuesta. Escribe únicamente en un espacio de borradores y carece de permiso de envío. | Produce un artefacto no final para revisión. Omite compromisos sin respaldo, marca la decisión faltante y asigna un revisor calificado. | Registra fuentes, versiones de plantilla y política, identificador del borrador, marcadores de afirmaciones sin respaldo y disposición del revisor. Prueba promesas no autorizadas, datos sensibles e instrucciones adversariales recuperadas. El dueño de contenido resuelve criterios pendientes. |
| Enviar una respuesta aprobada | Usa una operación de envío separada y una identidad autorizada solo para el canal y destinatario previstos. El acceso queda vinculado al recurso de mensajería. | Ejecuta una acción externa únicamente si destinatario, referencia de contenido, autorización, aprobación vigente y estado de prevención de duplicados coinciden. | Registra destinatario, canal, referencia aprobada, identidad remitente, decisión de política, aprobación, resultado y clave de idempotencia. Prueba cambios de contenido, vencimiento, reintentos y caída del canal. El dueño de mensajería opera el servicio; quien envía conserva la decisión de negocio. |
El registro de cada fila debe responder preguntas concretas sin convertirse en una copia ilimitada de la conversación. Tiene que permitir reconstruir quién pidió qué, qué capacidad y versión de política se aplicaron, qué clases de fuentes y herramientas intervinieron, cómo resolvieron la autorización y la aprobación y qué resultado se produjo. Secretos y contenido sensible deben redactarse o limitarse conforme a las reglas internas de privacidad, seguridad y gestión documental.
El lanzamiento requiere evidencia de que el servicio permitido y las denegaciones previstas funcionan en condiciones semejantes al despliegue. No basta con comprobar respuestas correctas. La batería debe incluir acceso cruzado entre cuentas, herramientas sin autorización, información obsoleta, contenido recuperado manipulado, datos prohibidos, elusión de aprobación, parámetros modificados, reintentos duplicados, fallas de dependencias, intentos de exfiltración y cadenas descontroladas. Cada caso debe producir un resultado observable y atribuible a una política.
En producción, las métricas deben permanecer al nivel de la capacidad: uso inesperado de herramientas, denegaciones repetidas, fallas de autorización, cambios entre aprobación y ejecución, secuencias anómalas, deriva, latencia, consumo de recursos y fallas. La organización define qué señales conserva y por cuánto tiempo según su riesgo y privacidad. También asigna responsables diferenciados para el comportamiento del servicio, las concesiones de acceso, las derivaciones de negocio y los incidentes de seguridad.
La forma más segura de avanzar es lanzar la capacidad útil más pequeña solo cuando sus éxitos y rechazos sean observables, y ampliar la autoridad mediante cambios revisados, no mediante ajustes de instrucciones aislados. Cuando intervienen datos sensibles, memoria persistente, acceso privilegiado, compromisos externos, cambios destructivos o incidentes, deben participar los responsables internos de seguridad, identidad, privacidad, registros, riesgo y servicio. Los juicios legales, regulatorios u otros juicios profesionales de alto impacto corresponden a especialistas calificados y a procesos gobernados por separado.
Es un servicio empresarial cuyas tareas, datos, identidades, herramientas, acciones y propietarios están definidos expresamente. Sus límites se aplican fuera del modelo mediante permisos, políticas de ejecución, registros, rechazos y rutas de escalamiento.
Se crea una fila por cada capacidad visible, como leer un caso, preparar un borrador o enviar una respuesta. En cada fila se registran actor, alcance de datos, operación, identidad actuante, recurso, techo de acción, aprobación, límites, evidencia, pruebas, métricas y responsable.
Debe definir fuentes y registros elegibles, permisos del usuario, filtros, vigencia y clases de confianza. El historial de sesión y la memoria persistente requieren reglas independientes de aislamiento, validación, tamaño, vencimiento y eliminación, además de una lista de datos que nunca pueden guardarse.
No. La aprobación acepta una propuesta específica, pero no reemplaza la autorización del sistema de destino, no reduce permisos permanentes excesivos y no habilita una decisión prohibida. Si cambia la acción aprobada, debe realizarse una validación nueva.
Debe hacerlo ante tareas fuera de alcance, datos no elegibles, autorización insuficiente, evidencia ausente u obsoleta, juicio especializado, dependencias caídas, límites operativos o señales de seguridad. Puede ofrecer ayuda parcial segura y derivar contexto no sensible al responsable, pero la ejecución debe permanecer detenida.
Este artículo se investigó a partir de las siguientes fuentes:
Contamos cómo aterriza de verdad la IA dentro de una empresa. Partimos de fuentes identificadas, distinguimos lo que encontramos de lo que pensamos y usamos IA como apoyo para investigar y redactar, bajo controles editoriales documentados. No reemplazamos la revisión de un experto.
Diseña un flujo controlado de redacción con IA que separa evidencia y prosa, asigna revisiones claras y registra los cambios que alteran decisiones.
Método práctico para convertir un flujo de negocio acotado en casos reproducibles, con cobertura, criterios, revisión y evidencia protegida.
Diseña un inventario mantenible de usos de IA, clasifica su exposición con cuatro dimensiones y deriva cada caso a una revisión proporcional y trazable.
