Agentes de IA empresariales
que puede controlar y auditar
Primo Epic es una plataforma de agentes de IA que se ejecuta en su propia infraestructura. Los agentes revisan contratos, verifican facturas según la política de la empresa y procesan hojas de cálculo. Cada cambio espera la aprobación de un empleado, cada decisión queda registrada con su razonamiento y el acceso sigue sus roles y reglas de seguridad.
Un robot repite pasos que están escritos.
Cuando una excepción no está en el script del robot, la tarea pasa a un empleado, que consulta el reglamento, los documentos relacionados y el historial de la operación. El razonamiento detrás de la decisión rara vez queda registrado.
Un agente decide dentro de las reglas que usted define y registra por qué.
Reúne los documentos y los datos, los compara con las reglas de la empresa y prepara el resultado para su aprobación o pasa la decisión a un empleado, con la cláusula del reglamento en la que se basó y cada paso registrado.
Los empleados se ocupan de las excepciones y las decisiones, no de buscar y cotejar a mano.
Agentes para el trabajo que requiere criterio, no solo repetición
Verificación de facturas y documentos
Análisis de hojas de cálculo
Respuestas a partir de políticas y bases de conocimiento
Robots de Primo RPA como herramientas
Conexión con los sistemas de la empresa
Lo que hace aceptable a un agente de IA en una empresa no es lo que puede hacer, sino hasta qué punto se puede controlar. Primo Epic sitúa ese control en la plataforma, no en el prompt.
Control
Dos capas de control, una de ellas independiente del modelo
Política — sus reglas
- —Reglas de la empresa para el caso, redactadas a partir de su reglamento: formulación para el modelo, severidad y cita de la cláusula
- —Las mantiene un abogado o un metodólogo, con versiones, y se publican sin programador
- —El modelo lee las reglas y las sigue. Como cualquier modelo de lenguaje, puede pasar alguna por alto
Controles del sistema — aplicados por el código de la plataforma
- —Límites de ejecución: pasos, tokens y tiempo por tarea
- —Herramientas permitidas: todo lo que está fuera de la lista se bloquea o se envía a confirmación
- —Filtro de entrada y salida: palabras prohibidas e instrucciones inyectadas en el texto de los documentos
- —Enmascaramiento de datos personales en las respuestas del modelo
- —La reacción se define por control: bloquear, enviar a confirmación o enmascarar. Los valores se fijan para la plataforma y se ajustan por agente o por paso
Los cambios en documentos y datos esperan la decisión de un empleado sobre cada modificación. Las reglas de confirmación se fijan al publicar el agente y, durante la ejecución, solo pueden endurecerse. Por defecto, ninguna acción que modifique datos se ejecuta sin confirmación.
Una decisión que no se puede explicar no se puede auditar. Para cada tarea, la plataforma registra qué decidió el modelo, qué herramienta usó y quién aprobó el resultado.
Trazabilidad
Cada decisión se puede reconstruir después
Cada paso del modelo
Cada paso del agente con su duración y los tokens que usó el modelo, para reproducir una ejecución en orden.
Cada llamada a herramientas
Qué herramienta llamó el modelo, con qué argumentos y qué obtuvo.
Cada decisión sobre una modificación
La cláusula, el código y la severidad de la regla, el texto original y el propuesto, el razonamiento del modelo y quién la aceptó o rechazó.
Cada control del sistema que se activó
Los límites alcanzados, las herramientas bloqueadas y el contenido filtrado aparecen en el mismo registro que el paso que los provocó.
Cada traspaso
Cuando el asistente pasa una solicitud a un agente concreto, el registro muestra a quién y por qué.
Un registro de auditoría aparte
Concesión y revocación de permisos, cambios de rol, cuentas bloqueadas e intentos de acceso denegados. Los registros se pueden exportar a sistemas externos, incluido un SIEM.
El control y los registros solo importan si la plataforma encaja en el modelo de seguridad corporativo. El acceso, la ejecución y la conexión de herramientas siguen las reglas que su equipo de seguridad ya aplica.
Seguridad
Diseñada para superar su revisión de seguridad
Dentro de su perímetro
La plataforma, los datos, los archivos y los registros se almacenan en sus servidores y no sale telemetría. Las conexiones salientes van solo al modelo, a los sistemas conectados y a las herramientas que usted aprueba.
Ver arquitectura de despliegue →Su inicio de sesión y sus grupos
Los usuarios inician sesión a través de su proveedor OIDC o del Keycloak incluido, con grupos de LDAP o Active Directory. La plataforma no almacena contraseñas propias.
Roles y permisos sobre objetos
Cuatro roles definen secciones y acciones. Los permisos en cuatro niveles controlan el acceso a cada agente, modelo, servidor y política. Los derechos se verifican en el servidor en cada acción y los rechazos quedan registrados.
Los agentes actúan con los derechos del usuario
Un agente actúa en nombre del empleado que asignó la tarea y no puede hacer lo que ese empleado no tiene permitido. Cada empleado ve solo sus propias conversaciones.
Herramientas revisadas por seguridad
Un administrador marca un servidor de herramientas como de confianza solo después de su revisión de seguridad. Hasta entonces, toda acción que no sea de solo lectura requiere confirmación.
Ejecución de código aislada
El código que el agente escribe para los cálculos se ejecuta en un contenedor desechable sin acceso a la red. Los tokens de acceso a modelos y herramientas se almacenan cifrados.
Los chatbots en la nube y los agentes resuelven problemas distintos. La diferencia está en dónde se ejecuta el trabajo y quién mantiene el control del resultado.
En qué se diferencia un agente de un chatbot
Chatbot sobre un modelo en la nube
- —Se ejecuta en la nube del proveedor del modelo; el proveedor decide qué modelos y conectores están disponibles
- —Responde sobre todo con texto; las acciones en los sistemas pasan por los conectores del proveedor
- —El control y los registros quedan del lado del proveedor
Agente de Primo Epic
- —Se ejecuta en sus servidores; usted elige el modelo
- —Corrige el documento, prepara el registro en el sistema y llama a robots de Primo RPA, con confirmación antes de modificar datos
- —Tarjetas de confirmación, controles a nivel de plataforma y un registro de pasos que se guarda dentro de su perímetro
No todos los procesos encajan. Esta es una lectura honesta de dónde Primo Epic rinde mejor y dónde quizá todavía no sea la opción adecuada.
Cuándo Primo Epic es la opción adecuada
Buen encaje
- —Contratos, facturas, solicitudes o informes que deben verificarse según un reglamento escrito
- —Decisiones que necesitan un rastro razonado y auditable que un auditor interno pueda seguir
- —Excepciones que hoy los robots pasan a los empleados
- —Datos que deben permanecer dentro del perímetro de la empresa
- —Documentos escaneados, con Primo AI Server para el reconocimiento
A tener en cuenta
- —No hay un reglamento escrito ni un conjunto de reglas en el que basar las decisiones
- —No hay criterios de éxito acordados antes del piloto
- —No hay acceso a un modelo de lenguaje: un servidor con aceleradores, una pasarela corporativa o un modelo en la nube aprobado
- —Procesos que deben ejecutarse de forma totalmente desatendida; hoy una tarea la inicia un empleado o un sistema que la invoca
- —Entornos que exigen una certificación de seguridad específica de la plataforma; los requisitos se revisan antes del piloto
Un despliegue medido,
con controles integrados.
Los plazos son habituales para un despliegue inicial y dependen de la preparación de la infraestructura y del alcance de las políticas. Las cifras describen el enfoque de implantación y el diseño de la plataforma, no resultados de clientes.