Hay una escena que se repite en muchas pymes: un responsable ve una demo de agente de IA, sonríe cuando responde rápido y luego pregunta lo lógico: “¿Y qué puede leer exactamente?”. Esa pregunta no frena la innovación; la hace viable. Mi tesis es clara: un agente de IA interno solo merece entrar en producción si su acceso a datos está limitado por tarea, registrado y revocable en minutos.
Si el agente ve más de lo necesario, el ahorro de tiempo suele convertirse en deuda de control.
La discusión no debería empezar por el modelo, sino por el permiso. Y eso cambia mucho según el puesto. No necesita ver lo mismo un agente que redacta respuestas de soporte, otro que prepara borradores de compras o uno que resume incidencias de almacén. El principio útil aquí es el mismo que en seguridad clásica: mínimo privilegio. Pero en IA hay una diferencia importante: el contexto también es un permiso. Darle contexto de más no solo abre datos; también mezcla tareas, duplica riesgo y hace más difícil entender por qué una respuesta salió como salió.
La regla práctica: acceso por tarea, no por entusiasmo
OpenAI insiste en que escalar IA en empresa no va solo de desplegar herramientas, sino de crear condiciones para que las personas confíen en ellas, las usen y mejoren con el tiempo, con gobernanza, calidad y flujo de trabajo bien diseñados. La guía para empresas subraya precisamente que el avance sostenible depende de gobernanza que habilite velocidad, evaluación de calidad y trabajo híbrido con revisión humana. (openai.com)
Llévalo a una regla sencilla: antes de dar acceso a un agente, define tres cosas por escrito. Primera, qué problema resuelve. Segunda, qué fuentes puede consultar. Tercera, qué está prohibido tocar aunque “ayude”. Si no puedes responder eso en una reunión corta, el agente aún no está listo.
Piensa en una oficina como en una nave industrial. No todas las personas pueden entrar en todas las zonas, aunque trabajen en el mismo edificio. Con un agente de IA pasa igual: el “espacio” no es físico, pero el efecto es parecido. Una conexión a correo, ERP, CRM, documentación interna y almacenamiento compartido no es una sola puerta; son varias, y cada una amplía el alcance de un fallo.
Qué puede ver de verdad un agente interno
En la práctica, un agente interno suele necesitar cuatro tipos de datos: contenido de la tarea, contexto operativo, permisos transaccionales y señales de seguimiento. El error común es mezclarlo todo.
- Contenido de la tarea: el ticket, el pedido, el contrato o la incidencia concreta.
- Contexto operativo: el cliente, la unidad, el idioma, la ventana de entrega, el SLA.
- Permisos transaccionales: leer, proponer, aprobar o ejecutar. No siempre debe poder hacer las cuatro cosas.
- Trazabilidad: quién pidió la acción, qué fuentes consultó y qué cambió.
Un agente de atención al cliente puede necesitar ver historial del caso y estado del pedido, pero no nóminas ni presupuestos completos. Uno de compras puede ver proveedores, precios y plazos, pero no datos personales que no aportan a la decisión. Y uno de operaciones puede necesitar cruzar inventario y pedidos abiertos, pero no acceder a todo el contenido de los correos de dirección.
Aquí conviene ser incómodo: muchas empresas justifican accesos amplios con la frase “ya lo vería una persona”. Esa comparación falla. Una persona improvisa, pregunta y filtra. Un agente automatiza, escala y repite. Si le das demasiado, no solo puede equivocarse más lejos; también puede equivocarse más veces.
El caso realista: el agente útil era más pequeño de lo que parecía
Imagina una pyme industrial con equipo comercial, almacén y posventa. Quiere un agente para responder a consultas sobre estado de pedidos y plazos de entrega. La primera versión conectaba correo, ERP, gestor documental y bandeja de soporte. Funcionó en pruebas, pero empezó a devolver respuestas demasiado amplias: mencionaba descuentos internos, nombres de proveedores y notas de negociación que no hacían falta.
La solución no fue “darle mejor IA”. Fue recortar. El agente pasó a ver solo el pedido, el cliente, el stock confirmado, la ventana logística y el historial del ticket. Además, cada respuesta quedó registrada con fuentes y un motivo de acceso. Resultado: menos superficie de riesgo, menos confusión interna y más confianza del equipo para usarlo de verdad.
Ese ejemplo muestra una lección incómoda: a veces el proyecto mejora cuando le quitas datos, no cuando le añades más contexto. En IA, más información no siempre significa más inteligencia; a menudo significa más exposición.
Registro y revocación: lo que no se ve acaba costando
Si no hay logs, no hay gobierno. El registro no es un trámite técnico; es la memoria operativa del agente. Debe permitir responder a preguntas muy concretas: qué vio, cuándo lo vio, qué versión de datos usó, quién autorizó el acceso y cómo se revoca si cambia la función o hay un incidente.
La revocación también debe ser simple. Si un comercial cambia de equipo o un agente ya no gestiona una línea de producto, el acceso debe retirarse sin revisar veinte sistemas. La empresa madura no es la que da más permisos; es la que los retira rápido cuando dejan de tener sentido.
Tres preguntas para esta semana
- ¿Qué dos fuentes necesita realmente tu próximo agente y cuáles sobran?
- ¿Puedes revocar su acceso hoy sin tocar media empresa?
- ¿Tienes un registro legible de cada consulta y cada acción, o solo “funciona”?
Si esta semana tu equipo va a probar un agente interno, empieza por estas preguntas. En Codefuente vemos a menudo que el primer salto de calidad no es técnico, sino de criterio: decidir qué datos no debe ver la IA para que sí merezca trabajar dentro de la empresa.