Sus agentes ya viven en seis plataformas. Dataiku y Classie venden la capa que está por encima de todas

El consejero delegado de Dataiku resumió el problema con una frase que cualquier director de sistemas de un banco reconoce: pregunte a un banco cuántos servidores tiene y le darán la cifra exacta; pregúntele cuántos agentes de IA tiene y le darán una estimación.

La estimación no es dejadez. Hoy las áreas de negocio crean agentes en Copilot Studio, ingeniería los construye en Azure AI Foundry y Amazon Bedrock, los responsables de aplicaciones activan agentes en Salesforce y ServiceNow, el equipo de datos monta los suyos en Databricks y Snowflake, y hay empleados que instalan una extensión de navegador sin consultar a nadie. Cada plataforma tiene su consola, sus logs y su propia definición de agente.

Dos anuncios en una misma semana apuntan a ese hueco. Dataiku lanzó Agent Management, que según la empresa alcanza la disponibilidad general en octubre. Classie lanzó Supervise, que asegura estar ya disponible. Atacan el problema desde extremos opuestos, y esa diferencia es lo más útil.

Dos productos, dos puntos de entrada

Dataiku parte de las plataformas. Agent Management se conecta a las plataformas de agentes mediante sus API nativas y flujos de logs, y a entornos propios mediante OpenTelemetry. Dataiku menciona AWS Bedrock, Databricks, Google Vertex, Microsoft Copilot Studio, Azure Foundry, Salesforce Agentforce, Snowflake Cortex y su propia plataforma. Con eso construye un inventario único con la estructura, herramientas, modelos, responsable y finalidad de cada agente, sigue uso, coste y calidad, y mantiene registros de certificación, riesgo y pruebas programadas para los agentes de alto riesgo. El precio, según la empresa, combina una licencia anual por instancia y una tarifa de monitorización por agente.

Classie parte de los extremos. Supervise se presenta como una capa para descubrir y monitorizar agentes autorizados y no autorizados en navegadores, endpoints y entornos de cómputo. Classie afirma que registra transcripciones de lo que hizo cada agente, para quién y con qué datos; que puede alertar, restringir, redirigir o detener acciones en tiempo real con un motor Open Policy Agent; que imputa el gasto en tokens a personas y agentes, y que admite despliegue privado. La empresa no ha publicado documentación de producto más allá del anuncio, así que conviene tratar ese alcance como declarado.

En pocas palabras: Dataiku es más fuerte donde los agentes nacen en plataformas conocidas; Classie apunta a los agentes que nadie registró.

1. API y logs de las plataformas
2. OpenTelemetry del código propio
3. Navegadores y endpoints
4. Un inventario, con responsable y nivel de riesgo
5. Pruebas, política y gasto

• Agentes autorizados: API y logs de las plataformas · OpenTelemetry del código propio
• Agentes en la sombra: Navegadores y endpoints

Énfasis de DataikuÉnfasis de Classie

Qué resuelve una capa por encima de los proveedores

Un plano de control entre plataformas es bueno en cuatro cosas.

Contar. Una lista única de agentes, cada uno con su responsable, es el requisito previo de todo lo demás. Para una empresa española, esa lista es también el punto de partida del Reglamento europeo de IA: no se puede saber qué sistemas entran en las categorías de alto riesgo del anexo III, ni qué obligaciones de transparencia del artículo 50 aplican, sin saber primero qué agentes existen y qué hacen. El ómnibus digital aprobado este verano, el Reglamento (UE) 2026/1744, retrasó al 2 de diciembre de 2027 las obligaciones de alto riesgo del anexo III, pero mantuvo las de transparencia, que se aplican desde agosto de 2026. El calendario da algo de aire; no elimina el inventario.

Clasificar. No todos los agentes merecen el mismo escrutinio. Un plano de control que registra herramientas, acceso a datos y grado de autonomía puede ordenarlos por nivel de riesgo y asociar a cada nivel las pruebas y revisiones adecuadas. Es el mismo enfoque por niveles de riesgo sobre el que descansa el reglamento europeo, cuya supervisión en España corresponde a la AESIA.

Comparar. Coste por agente, tendencias de calidad y deriva de varias plataformas en una sola vista, en lugar de seis consolas con seis definiciones.

Encontrar huérfanos. Agentes cuyo responsable se fue, cuyas pruebas dejaron de ejecutarse o que nadie usa desde hace meses. Son los que provocan incidentes.

Qué no resuelve

No ve más de lo que exponen las plataformas. La profundidad de la integración varía según el framework. Un plano de control que lee la API de una plataforma puede ver la configuración del agente sin ver cada llamada a herramientas. Pregunte, plataforma por plataforma, qué campos se recogen realmente.

No sustituye a los controles nativos. La identidad, los permisos y el acceso a datos se siguen aplicando donde se ejecuta el agente. En entornos Microsoft, Entra Agent ID da a los agentes identidad propia, con responsables (sponsors) y acceso condicional, y Microsoft está unificando su registro de agentes en Microsoft Agent 365. Una capa entre proveedores debe leer esos controles, no competir con ellos.

Su telemetría es sensible. Las transcripciones contienen prompts, documentos recuperados y respuestas. Como explicamos en nuestro artículo sobre observabilidad de agentes, los datos de monitorización requieren las mismas decisiones de custodia que los datos que describen, RGPD incluido.

Cómo decidir

La prueba es sencilla: cuente sus plataformas de agentes. Si casi todo corre en un ecosistema, empiece por el registro y los controles de identidad de ese ecosistema y deje la capa entre proveedores para más adelante. Si ya hay agentes en tres o más plataformas, o si las áreas de negocio contratan agentes por su cuenta, una capa por encima de los proveedores empieza a compensar, porque el registro de un proveedor nunca listará con el mismo cuidado los agentes de sus competidores.

Es la lógica de poseer una sola vez las capas neutrales, que planteamos en nuestro artículo sobre qué construir una vez para todos los agentes. El inventario es una de ellas.

Antes de firmar, haga una prueba de dos semanas:

1. Concilie. Compare el inventario que descubre la herramienta con lo que cada equipo de plataforma cree tener. Las diferencias son el hallazgo.
2. Compruebe la profundidad por plataforma. En las tres principales, confirme qué eventos se recogen: solo configuración, o también llamadas a herramientas y acceso a datos.
3. Asigne responsables a todos los agentes descubiertos durante la prueba. Un agente sin responsable es candidato a apagarse.
4. Decida dónde viven las transcripciones. Retención, acceso y región de los datos del propio plano de control, por escrito.
5. Conecte una acción. Elija una política, como impedir que un agente no registrado acceda a un sistema sensible, y pruébela de principio a fin.

En resumen

La proliferación de agentes sigue el camino de la proliferación de SaaS y de la nube: primero el crecimiento, después la factura, luego el inventario. Dataiku y Classie apuestan a que la fase del inventario empieza ahora. Compre una de ellas o parta del registro de su plataforma principal, el primer entregable es el mismo: la lista de todos los agentes, con un responsable junto a cada uno. Sin esa lista, la pregunta de quién responde por las acciones de un agente no tiene a quién dirigirse.