TelediAGENTES INTERNOSEnglish

Un agente con acceso a todo es un riesgo, no una mejora.

Un agente con acceso a todo y sin registro no es una herramienta de productividad: es un incidente de seguridad pendiente de fecha. Construimos agentes internos con permisos acotados por rol y un registro de auditoría que resiste una revisión de seguridad.

0Acciones ejecutadas sin quedar registradas

02 / Por qué un agente interno sin permisos acotados es un riesgo, no una mejora

Por qué un agente interno sin permisos acotados es un riesgo, no una mejora


  • 01

    Credenciales de servicio compartidas

    Es habitual dar al agente el mismo usuario de servicio que usa la integración por lotes nocturna, con acceso a todo lo que ese usuario puede tocar. El agente hereda un alcance que nadie diseñó para él.


  • 02

    Sin registro de qué acción tomó y por qué

    Si el agente modifica un registro o envía un correo, y no queda constancia de la instrucción que lo originó, no hay forma de reconstruir el incidente cuando alguien pregunta por qué ocurrió.


  • 03

    Ninguna frontera entre leer y escribir

    Un agente al que se le concede lectura para responder preguntas y, sin distinción adicional, también puede escribir, acaba ejecutando acciones que nadie revisó ni aprobó de forma explícita.


  • 04

    Ningún proceso de baja para el agente

    Cuando una persona deja la empresa, hay un proceso de baja que retira sus accesos. Un agente que se creó para una prueba y sigue activo seis meses después, con las mismas credenciales, normalmente no pasa por ningún proceso equivalente.


  • 05

    Confianza en la respuesta, no en el proceso

    Evaluar si la respuesta suena bien no dice nada sobre si el agente tenía permiso para generarla ni sobre si la acción que ejecutó era la correcta. Sin control de proceso, la calidad de la respuesta es la única barrera, y no es suficiente.

03 / Cómo lo construimos

Cómo lo construimos

  1. 01

    identidad

    Cada agente tiene una identidad propia, distinta de cualquier usuario humano o de servicio

  2. 02

    rol y alcance

    Permisos definidos por rol: qué sistemas, qué acciones y bajo qué condiciones

  3. 03

    instrucción

    Recepción de la tarea y del contexto necesario para ejecutarla

  4. 04

    ejecución acotada

    La acción se valida contra el alcance del rol antes de tocar el sistema de destino

    45 ms

  5. 05

    punto de revisión

    Las acciones de alto impacto quedan pendientes de aprobación humana antes de ejecutarse

  6. 06

    registro

    Instrucción, acción, sistema afectado y resultado, escritos en el registro de auditoría

    12 ms

  7. 07

    baja del agente

    Cierre de rol acordado con su equipo de seguridad: qué tareas deja de ejecutar y qué queda documentado para la siguiente auditoría

04 / Integraciones

Integraciones


  • Microsoft 365

  • Google Workspace

  • Slack

  • Notion

  • Jira

  • A3

  • SAP

  • PostgreSQL

05 / Garantías

Garantías


Por rol
Alcance de permisosDiseñado y revisado con su equipo de seguridad
100 %
Acciones con registro de auditoría
Acordada
Baja de acceso al cerrar el rol del agenteCon su equipo de seguridad, no solo desactivada
Humana
Aprobación previa por encima del umbral de impacto acordado

06 / Cumplimiento

Cumplimiento


  • Registro auditable de cada acción ejecutada por un agente interno

    Reglamento de IA de la UE, obligaciones de trazabilidad, de aplicación desde el 2 de agosto de 2026


  • Alcance de permisos revisado por su equipo de seguridad en cada cambio de rol o baja del agente

    Principio de minimización, RGPD art. 5.1.c


  • Supervisión humana obligatoria en acciones de alto impacto

    Reglamento de IA de la UE, art. 14, supervisión humana


  • Preparado para inspección de la AESIA sobre sistemas de IA usados internamente

    Reglamento de IA de la UE, régimen sancionador de hasta 15 M€ o el 3 % de la facturación global

07 / Proceso

Proceso


  1. 1-2

    Mapeo de tareas y permisos actuales

    Identificación de las tareas candidatas y del acceso real que hoy tienen las personas que las ejecutan, no el acceso que figura en el documento de políticas.


  2. 2-3

    Diseño de roles y alcance

    Definición del alcance mínimo de permisos por agente y de qué acciones requieren aprobación humana previa.


  3. 3-6

    Implementación

    Construcción del agente, su identidad propia y la integración con los sistemas dentro del alcance definido.


  4. 6-7

    Registro y revisión de seguridad

    Puesta en marcha del registro de auditoría y revisión conjunta con su equipo de seguridad antes de producción.


  5. continuo

    Operación

    Revisión periódica del alcance de permisos a medida que cambian las tareas del agente.

08 / Preguntas frecuentes

Preguntas frecuentes

¿Qué diferencia a un agente interno de una automatización con RPA?
El agente interpreta instrucciones en lenguaje natural y decide qué acción tomar dentro de su alcance; el RPA ejecuta un guion fijo. Esa flexibilidad es la razón por la que el control de permisos es más crítico, no menos.
¿Puede el agente borrar o modificar datos sin supervisión?
Solo dentro del alcance definido para su rol, y las acciones marcadas como de alto impacto quedan pendientes de aprobación humana antes de ejecutarse.
¿Cómo sabemos qué hizo el agente la semana pasada?
El registro de auditoría guarda cada instrucción recibida, cada acción ejecutada y el resultado, con marca de tiempo. Es el mismo tipo de registro que se pediría a un empleado con acceso a esos sistemas.
¿Qué pasa si detectamos un comportamiento no deseado?
Se activa el mismo proceso de baja que se usaría para retirar el acceso de una persona: cierre de rol acordado con seguridad, no una credencial suelta que haya que perseguir sistema por sistema.
¿El agente puede usar la misma cuenta de correo o de Slack que una persona?
No. Cada agente opera con una identidad propia y visible, para que quien reciba una acción o un mensaje sepa que no proviene de una persona.
¿Cómo se decide qué tareas puede automatizar el agente y cuáles no?
Con su equipo de seguridad, durante la fase de diseño de roles: se clasifican las acciones por impacto y se decide cuáles requieren aprobación humana antes de dejarlas en modo autónomo.
¿Sirve para varios departamentos o hay que construir un agente por área?
Cada agente se diseña con el alcance de un rol concreto. Varios departamentos pueden compartir la misma infraestructura de identidad y registro, con roles distintos para cada uno.

09 / Servicios relacionados

Servicios relacionados

10

Hablemos de su caso

Cuéntenos qué proceso quiere resolver y le respondemos con una propuesta técnica, no con un catálogo.

Escribir a hola@teledi.ai