Blog de César Cabrera — IA aplicada

Salesforce le quita la pantalla al CRM. Lo que eso exige de tus datos

consultas@cesarcabreraai.com (César Cabrera) — Fri, 25 Sep 2026 00:00:00 +0000

Respuesta corta: Salesforce ha presentado AIforce, una capa que permite trabajar con el CRM sin abrir el CRM. Un agente —en Claude, en Slack o donde trabaje el usuario— consulta registros, dispara flujos y actúa sobre cientos de fichas a la vez, respetando los permisos existentes. Es un cambio importante, y no es un cambio de interfaz: es una factura que se pasa al modelo de datos.

Marc Benioff lo formuló en la apertura de Dreamforce 2026 como una «revolución de la interfaz». Patrick Stokes fue más directo: la interfaz «a menudo se interpone», y la IA «la desagrega y la sustituye». Conviene mirar qué hay debajo de la frase.

¿Qué es AIforce y qué lo sostiene?

AIforce es la versión empaquetada de Headless 360, anunciado el 19 de agosto. Headless 360 expone cada nube de Salesforce como capacidad reutilizable que cualquier agente autorizado puede descubrir e invocar mediante estándares abiertos. AIforce es la parte que se vende; Headless 360 es la superficie técnica que hay debajo.

Las piezas que se presentaron:

Claudeforce: integración con Claude de Anthropic mediante un servidor MCP con 37 competencias de ventas preconstruidas, más de 40 adicionales vía el plugin de Claude Code. En beta abierta a través de AppExchange.
Slackforce: contexto de Salesforce dentro de Slack, con interfaces vivas (Surfaces) y vinculación de conversaciones a registros.
Agentforce Coworker: un agente dentro de Lightning que invoca a los agentes ya desplegados, operando con los permisos del usuario.
Koa: el primer modelo de razonamiento de Salesforce específico para CRM, construido con NVIDIA sobre la arquitectura Nemotron 3 Super. Salesforce afirma que «igual o supera el rendimiento de los modelos líderes en acciones de CRM con 3 veces menos errores», entrenado sin datos de clientes y en pilotos iniciales.

Dos detalles me parecen más significativos que el resto. El primero, que la integración principal se apoya en MCP: el protocolo de contexto se está convirtiendo en el conector por defecto entre modelos y sistemas de empresa, y eso importa mucho más que cualquier producto concreto. El segundo, la insistencia en Zero Data Retention y en que los agentes operan «dentro de los permisos existentes». Ahí es donde el anuncio deja de ser una noticia de producto y pasa a ser un problema tuyo.

¿Por qué esto no arregla un CRM desordenado?

Porque un agente que actúa sobre cientos de registros a la vez amplifica lo que encuentre. Si el modelo de datos es bueno, va rápido. Si está sucio, va rápido en la dirección equivocada.

Los números del sector apuntan justo ahí. Una encuesta de WRITER con Workplace Intelligence, publicada el 7 de abril de 2026 sobre 2.400 respuestas (1.200 empleados no técnicos y 1.200 directivos), encontró que el 79 % de las organizaciones tiene dificultades para adoptar IA, un aumento de dos dígitos respecto a 2025. El 97 % de los directivos había desplegado agentes en el último año. Solo el 29 % veía retorno significativo.

El 97 % ha desplegado agentes. El 29 % ve retorno. La distancia entre esas dos cifras no la cierra un modelo mejor.

Hay un dato más de ese mismo estudio que explica bastante: el 67 % de los directivos cree que su empresa sufrió una filtración por herramientas de IA no aprobadas. Cuando la capa de agentes se convierte en la forma normal de tocar el CRM, «permisos existentes» deja de ser una línea en una ficha de producto y pasa a ser el perímetro real de tu información comercial.

¿Qué hace falta para que una capa así funcione?

Tres condiciones, y ninguna se compra:

1. Que el dato signifique una sola cosa

Un agente no interpreta contexto ambiguo como lo hace un comercial veterano. Si «cliente activo» significa una cosa en el CRM, otra en facturación y otra en la cabeza del responsable de zona, el agente elegirá una y responderá con seguridad absoluta. El trabajo previo es aburrido y no tiene demo: decidir qué significa cada campo y dejarlo escrito.

2. Que los permisos estén donde se dice que están

En la mayoría de los CRM que reviso, los permisos son teóricos: existe el esquema de clientes asignados por comercial, y existe también el informe general que todo el mundo puede exportar. Con una interfaz, esa contradicción se sostiene porque nadie navega hasta ahí. Con un agente al que le preguntan en lenguaje natural, se cae el primer día.

3. Que haya un punto donde alguien decide

Actuar sobre cientos de registros a la vez es potente y es exactamente donde hace falta un control humano explícito. No un aviso genérico: una regla que diga qué volumen y qué tipo de operación requieren confirmación, y de quién.

¿Y si no usas Salesforce?

La mayoría de las empresas con las que trabajo no lo usan. El anuncio sigue siendo relevante por lo que anticipa: el proveedor grande está convirtiendo su producto en capacidades invocables por agentes, y ese patrón va a bajar al resto del mercado. Cuando llegue a tu ERP o a tu herramienta interna, la pregunta no será qué modelo conectas, sino si tu sistema puede exponer operaciones con permisos fiables y registro de quién hizo qué.

Eso se puede preparar antes de tener agente, y de hecho es mejor prepararlo antes. Es el mismo trabajo que ya había que hacer para integrar dos sistemas entre sí: definir qué operaciones existen, quién puede ejecutarlas y qué queda registrado. La diferencia es que ahora el consumidor de esa interfaz no es un programador que lee la documentación, sino un modelo que va a probar lo que le dejes probar.

Mi lectura, en una línea: AIforce no es una razón para comprar nada. Es una razón para ordenar el modelo de datos y los permisos antes de que algo los use en serio.

El AI Act se ha retrasado. Avisar de que hablan con una IA, no

consultas@cesarcabreraai.com (César Cabrera) — Fri, 25 Sep 2026 00:00:00 +0000

Respuesta corta: el reglamento europeo de IA entró en aplicación general el 2 de agosto de 2026. Las obligaciones más duras —las de los sistemas de alto riesgo del anexo III— se han aplazado al 2 de diciembre de 2027. Pero la obligación que afecta a casi cualquier empresa con un bot atendiendo clientes ya está vigente: si un sistema de IA interactúa con una persona, hay que decírselo a esa persona.

Ese matiz se ha perdido en el ruido del aplazamiento. Conviene separar las dos cosas.

¿Qué entró en vigor el 2 de agosto de 2026?

El artículo 113 fija esa fecha como aplicación general del reglamento. Todo lo que no tenga una fecha propia, se aplica desde entonces. Y el capítulo IV —el artículo 50, obligaciones de transparencia— no tiene fecha propia.

El artículo 50 no va de alto riesgo. Va de todos los sistemas de IA que interactúan con personas. En concreto:

Apartado 1: quien despliega un sistema pensado para interactuar directamente con personas tiene que informar a esas personas de que están ante una IA, salvo que resulte obvio por el contexto.
Apartado 2: quien genera audio, imagen, vídeo o texto sintético tiene que marcar esas salidas en formato legible por máquina y detectable como generado artificialmente.
Apartado 4: quien publica deepfakes o texto generado sobre asuntos de interés público tiene que declararlo, salvo que haya pasado revisión editorial humana con un responsable identificable.

Junto a eso entraron el régimen sancionador (artículos 99 y 100), el marco de gobernanza y las competencias de supervisión sobre los modelos de propósito general. Las multas del reglamento llegan a 15 millones de euros o el 3 % del volumen de negocio mundial, la cifra que sea mayor.

Un detalle de calendario que sí se movió: el marcado legible por máquina del apartado 2 se aplica de inmediato a los sistemas puestos en el mercado después del 2 de agosto de 2026, y los que ya estaban antes tienen hasta el 2 de diciembre de 2026.

¿Qué se ha aplazado exactamente?

El instrumento se llama Digital Omnibus on AI y alcanzó acuerdo provisional el 7 de mayo de 2026. Los desplazamientos relevantes:

Nuevo calendario Alto riesgo del anexo III (clasificado por uso): del 2 de agosto de 2026 al 2 de diciembre de 2027. Alto riesgo del anexo I (producto regulado): del 2 de agosto de 2027 al 2 de agosto de 2028. Espacios controlados de pruebas nacionales: al 2 de agosto de 2027.

Lo aplazado es la parte cara: evaluación de conformidad, documentación técnica, marcado CE, registro en la base de datos europea, supervisión humana documentada. Dieciséis meses más para quien hace cribado automatizado de candidatos, scoring de crédito, biometría o gestión de infraestructura crítica.

Y aquí está el problema de leer el titular y quedarse tranquilo: la mayoría de las empresas con las que trabajo no tienen nada de eso. Un agente que responde dudas sobre el estado de un pedido no es alto riesgo. Un CRM que ordena la cartera comercial por comercial asignado no es alto riesgo. Lo que sí les aplica —el artículo 50— es justamente lo que no se ha aplazado.

El aplazamiento alivia a quien hace scoring de crédito. No alivia a quien tiene un bot en WhatsApp.

¿Cómo se cumple el artículo 50 en un agente de atención al cliente?

No hace falta un descargo legal de tres párrafos antes de cada conversación. Hace falta que quede claro, a la primera y sin buscarlo. En los procedimientos que escribo, esto se traduce en cuatro decisiones concretas:

El primer mensaje identifica qué es. Una línea basta: quién atiende, que es un sistema automático, y para qué sirve. Va antes de pedir el primer dato al cliente, no después.
El remitente no simula ser una persona. Un perfil llamado «Ana, atención al cliente» cuando Ana no existe es exactamente lo que el artículo 50 quiere evitar. Si el asistente tiene nombre, que se lea como asistente.
La salida a persona está visible siempre. No enterrada tras cinco intentos fallidos. Esto ya lo pedía el sentido común; ahora además sostiene la parte de «salvo que resulte obvio por el contexto», porque un flujo con derivación explícita deja claro qué es automático y qué no.
Si el sistema genera contenido que se publica, se marca. Aquí es donde la mayoría no está mirando: afecta a fichas de producto, descripciones, respuestas públicas y cualquier imagen generada.

Coste real de los tres primeros puntos: un cambio de copia y una regla de enrutado. Horas, no un proyecto.

La parte que no es legal, es de arquitectura

El artículo 50 no obliga a llevar un registro de conversaciones. Pero el día que alguien discuta si se le informó o no, la única defensa es el histórico. Y ahí el obstáculo no suele ser jurídico: es que el agente vive en una herramienta que no permite exportar las conversaciones, o que las borra a los treinta días.

Es el mismo patrón que veo en todo lo demás. La obligación regulatoria acaba siendo un requisito técnico que había que cumplir igualmente por razones operativas. Quien no puede reconstruir una conversación con un cliente tampoco puede auditar por qué su agente respondió mal, ni medir qué preguntas se repiten, ni entrenar al equipo con casos reales.

¿Qué haría yo esta semana?

Tres cosas, en este orden:

Inventario. Lista de todos los puntos donde una IA habla con un cliente o con un candidato. Incluye el chat de la web, el bot de WhatsApp, las respuestas automáticas de correo y cualquier formulario que redacte algo. Casi siempre son más de los que se recuerdan.
Revisar el primer mensaje de cada uno. Si no dice que es automático, se corrige hoy.
Comprobar que el histórico es exportable. Si no lo es, ese es el trabajo real que hay que planificar.

Ninguno de los tres es un proyecto de cumplimiento normativo. El proyecto de verdad llega si alguien decide esperar a diciembre de 2027 y abordarlo todo junto.