Agentes de IA para empresas: qué procesos delegar ya

Alguien de tu equipo abre el correo el lunes, copia el NIF de un pedido en el CRM y media hora después vuelve a teclear los mismos datos en el ERP. Nadie lo llama proceso porque nadie lo ha escrito nunca, pero pasa cada semana y cuesta dinero. Lo que ha cambiado este año no es que los modelos escriban mejor: es que ya ejecutan ese trabajo sobre el software donde vive. Por eso la conversación sobre agentes de IA para empresas ha dejado de ser «qué modelo elijo» y ha pasado a ser otra más rentable: por qué mecanismo delego cada proceso.

En Docastix montamos automatizaciones y agentes que operan sobre sistemas ya en producción: el CRM del cliente, su ERP, su correo y sus herramientas internas. Lo que no sale en las demos es lo que decide si aquello sobrevive al tercer mes: qué se delega, qué se queda con una persona y qué pasa cuando el agente se equivoca.

Respuesta rápida: ¿qué procesos puede automatizar hoy un agente de IA?

Se delega bien todo proceso repetitivo, con reglas escritas y error barato y reversible: cualificar y enrutar leads, mantener al día el CRM, pasar documentos a sistema, resolver el primer nivel de soporte y generar informes recurrentes. Lo que decide el resultado no es el modelo, es el mecanismo: si el sistema tiene API se integra por API, y el agente que maneja un navegador es el último recurso, no la novedad que hay que comprar.

Quédate con tres ideas: la decisión es el mecanismo, no el modelo, el navegador es la puerta de servicio, no la principal y un proceso que nadie ha escrito no está listo para delegarse a nadie.

Qué ha cambiado en 2026: los modelos ya operan software

Durante tres años la IA en la empresa fue una caja de texto: preguntabas y contestaba, pero alguien tenía que coger esa respuesta y meterla en un sistema. Ahora el modelo puede meterla.

El ejemplo más claro es el anuncio de GPT-6 Astra de OpenAI, presentado como su mejor modelo de «computer use»: manejar un ordenador como lo haría una persona. Lo revelador son los ejemplos que elige la propia OpenAI: rellenar formularios en línea, actualizar registros de clientes en un CRM y organizar el calendario. Ni escritura creativa ni análisis estratégico. Backoffice. El trabajo que hoy hace alguien de tu equipo con dos pestañas abiertas.

Los números van en la misma dirección. En OSWorld 2.0, un banco de pruebas de tareas reales sobre un escritorio, alcanza un 72,6% frente al 65,7% del anterior, GPT-5.6 Sol, y con aproximadamente un 47% menos de tiempo por tarea. Ese segundo dato pesa: en un agente que trabaja sobre una interfaz el tiempo es coste directo, porque cada paso son capturas, razonamiento y tokens. Y está en la API de OpenAI, en Microsoft Azure y en Amazon Bedrock: ya no es un experimento con lista de espera.

El dato que casi nadie cita: una de cada cuatro tareas no sale

Aquí es donde la mayoría de artículos miran hacia otro lado. Un 72,6% en un banco de pruebas de manejo de ordenador significa que en torno a una de cada cuatro tareas no sale: un salto notable frente al 65,7% anterior y, a la vez, una tasa de fallo que ninguna empresa aceptaría de un proveedor humano sin nadie revisando.

El propio anuncio es honesto con sus límites. OpenAI reconoce que el modelo alcanza el umbral crítico en capacidades de ciberseguridad, que usa clasificadores que revisan su razonamiento en producción, y avisa de que «las comprobaciones de seguridad adicionales pueden ralentizar, pausar o detener trabajo legítimo». Contempla incluso pausar una tarea para que una persona revise la acción antes de continuar.

Y no es cosa de un solo fabricante. La documentación de computer use de Anthropic lo dice más crudo todavía: avisa de que el modelo puede equivocarse o alucinar al generar coordenadas y al elegir herramientas, recomienda centrarse en casos donde la velocidad no sea crítica y en entornos de confianza, y pide expresamente no usarlo «para tareas que requieran precisión perfecta o información sensible del usuario sin supervisión humana», con confirmación de una persona en cualquier decisión con consecuencias reales, como una transacción financiera. Cuando los dos fabricantes que te venden la capacidad coinciden en que pongas a alguien a revisar, la arquitectura ya está escrita.

Junta las dos cosas y tienes la arquitectura decidida: con esa tasa, delegar sin registro, sin reintentos y sin aprobación humana en lo sensible es imprudencia. Y un banco de pruebas no es tu ERP: con tus formularios raros el número será distinto, y solo lo sabrás midiéndolo. De ahí sale la matriz de arriba: donde el fallo es barato y reversible, lo dejas correr y vigilas; donde es caro o difícil de deshacer, el agente propone y firma una persona.

Esto ya no es cosa de los equipos técnicos

Hay un dato de adopción que cambia la conversación de sitio. En su informe sobre cómo las empresas están poniendo la IA a trabajar, OpenAI publica esta comparación: desde febrero, los usuarios empresariales activos semanales de Codex crecieron 108× en legal, 41× en ventas, 41× en recruiting y 26× en marketing, frente a 5× en ingeniería.

Ese 5× de ingeniería es la parte importante de la cita y la que se cae en casi todos los titulares. El crecimiento se ha ido a departamentos sin nadie capaz de montar lo que usan, y que son justo donde el trabajo consiste en mover información entre sistemas y perseguir estados.

De ahí salen dos patologías. La automatización de sombra: alguien de ventas monta su flujo con una cuenta personal, funciona tres semanas y, cuando cambia de puesto, nadie sabe qué se rompió ni qué datos salieron. Y la parálisis: dirección ve el riesgo, lo prohíbe todo y el equipo sigue copiando y pegando a mano. La salida es otra: que el departamento diga qué proceso le duele y que alguien lo construya con permisos, registro y mantenimiento. Cuando eso habla con personas —clientes, candidatos, proveedores— es un proyecto de agentes conversacionales, con su canal y sus límites escritos, no una suscripción.

Si hay API, no uses un agente de navegador

Este es el argumento central y va contra casi todo lo que vas a leer este año. Que un modelo sepa manejar un navegador es muy útil para el software sin otra puerta de entrada, pero no es el mecanismo por defecto, y confundir las dos cosas es la forma más cara de automatizar en 2026. Cuando hay API documentada, una integración o una orquestación con n8n gana en las cuatro cosas que importan:

• Coste. Una llamada a una API son milisegundos y céntimos. La misma tarea por navegador son decenas de pasos, capturas y razonamiento sobre píxeles que se pagan en tokens.
• Fiabilidad. Una API devuelve un error tipado que puedes tratar. Un agente sobre una interfaz depende de que el botón siga donde estaba: un rediseño o un aviso de cookies nuevo rompen el flujo sin avisar.
• Trazabilidad. Con API sabes qué se envió, cuándo y con qué resultado. Con navegador tienes una traza que hay que reconstruir, y eso pesa el día que alguien pregunta quién modificó un registro.
• Reintentos limpios. Una API bien diseñada permite repetir una operación sin duplicarla. Repetir un formulario a medio rellenar puede dejarte dos pedidos donde había uno.

¿Cuándo sí tiene sentido el navegador? Cuando no hay otra puerta: un ERP antiguo en un servidor de la oficina, el portal de un tercero, una intranet heredada. Ahí el agente compite contra una persona copiando y pegando, y gana; contra una API que ya existe, no. Pregunta siempre si el sistema tiene API: si la tiene y aun así te proponen manejarlo por pantalla, estás pagando de más y comprando fragilidad.

Los procesos que sí merece la pena delegar ya

Una lista de diez ideas sueltas no ayuda a decidir. Agrupados por mecanismo, sí.

Grupo 1: hay API, se integra y se orquesta. Es donde está el retorno de verdad y de lo que menos se habla porque no da titulares.

• Cualificación y enrutado de leads. Entra una solicitud por formulario, correo o WhatsApp; el agente la enriquece con lo que hay en el CRM, decide si encaja y la asigna con un resumen. Es el caso de PropPilot, un proyecto de cliente en PropTech: la primera respuesta a un lead pasó de horas a menos de 60 segundos, 24/7 en cuatro regiones.
• Mantenimiento del CRM. Notas de llamada, cambios de etapa, oportunidades muertas, deduplicación. Trabajo que la gente odia y hace mal por eso, con error reversible.
• Informes recurrentes. Ese Excel que alguien monta cada lunes cruzando tres exportaciones: se genera solo y la persona pasa a interpretarlo.
• Documentación interna. Un agente que responde sobre procedimientos, tarifas o condiciones a partir de documentos de la casa, citando la fuente.
• Soporte de primer nivel. Preguntas repetidas, estado de un pedido, dudas de facturación. El canal donde mejor funciona es el agente de IA en WhatsApp.

Grupo 2: decisión sensible, el agente propone y una persona aprueba. Presupuestos y descuentos fuera de tarifa, comunicaciones delicadas a cliente, altas de proveedor, cambios de datos bancarios, documentos con efecto contractual. El agente hace el 80% aburrido y una persona da al botón: acertar cien veces ahorra minutos, fallar una cuesta un cliente.

Grupo 3: no hay API y el proceso duele igual. El backoffice es el caso típico: facturas, albaranes y partes de trabajo que llegan en PDF y hay que teclear en un ERP que no expone nada. Aquí el agente con computer use se gana el sueldo, con dos condiciones: contraste automático de lo extraído contra el documento original y un umbral de confianza por debajo del cual la operación pasa a revisión humana.

Los que no, todavía

Decir que no a tiempo es la parte del trabajo que más dinero ahorra.

• Procesos que nadie ha escrito. Si al preguntar cómo se hace algo obtienes tres versiones de tres personas, no tienes un proceso: tienes una costumbre. Documéntala primero; a menudo descubres que sobran la mitad de los pasos.
• Excepciones constantes. Si cuatro de cada diez casos «son especiales», el agente pasará más tiempo escalando que resolviendo.
• Datos sucios. Un CRM con duplicados y clientes repetidos con tres nombres no mejora porque le pongas un agente encima. Empeora: el desorden se propaga rápido y sin testigos.
• Decisiones con coste asimétrico y sin marcha atrás. Precios, personal, resolución de contratos, cualquier cosa con efecto jurídico sobre una persona. Hay además obligaciones que mirar antes de empezar: el AI Act y los criterios para elegir herramienta los tratamos en herramientas de IA para empresas.
• Volumen ridículo. Un proceso que ocurre doce veces al año cuesta más automatizarlo que hacerlo a mano durante una década.

Cómo se monta de verdad un agente de IA para empresas: la arquitectura

Un agente en producción no es un modelo con un prompt largo: es un sistema con varias piezas, y las que deciden el resultado no tienen nada de espectacular.

La parte visible: modelos de OpenAI y Anthropic según la tarea —una clasificación se resuelve con uno pequeño por una fracción del coste—, orquestación con n8n, las APIs de los sistemas del cliente, Supabase como base de datos y de conocimiento con la búsqueda vectorial en PostgreSQL, Chatwoot para el canal de soporte, el CRM que la empresa ya usa y las herramientas a medida que hagan falta. Es el criterio de cualquier proyecto de aplicaciones a medida: se construye lo que no existe, no lo que puedes comprar.

La parte aburrida, la que separa un piloto de un sistema:

• Registro de cada acción. Qué hizo el agente, cuándo, con qué entrada, qué devolvió el sistema y con qué versión del prompt y del modelo. Sin esto no puedes auditar ni mejorar.
• Reintentos y control de duplicados. Reintentar está bien; reintentar creando dos facturas, no.
• Alertas cuando algo falla. Un agente que se rompe en silencio es peor que no tenerlo: nadie hace ese trabajo durante dos semanas y nadie lo sabe.
• Entorno de pruebas. Con datos reales anonimizados y una batería de casos, incluidos los raros: ahí mides tu tasa de acierto antes de producción.
• Aprobación humana en lo sensible, con la cola de revisión dentro de la herramienta donde esa persona ya trabaja, no en otro panel más.
• Permisos mínimos. Cuentas propias, alcance limitado al proceso, rotación y revocación en un clic. La lógica es la de seguridad en el desarrollo: asumir que algo saldrá mal y limitar el radio del daño.

Cuánto cuesta y cuándo se paga solo

Los rangos y el método para calcular el retorno ya están publicados en cuánto cuesta automatizar procesos con IA. Como orden de magnitud, una operación con agentes conectada a varios sistemas se mueve en la franja de 12.000-35.000 €, con un recurrente de 300-1.500 €/mes según volumen y criticidad; ahí está el desglose y los cuatro pasos para calcular el payback con tus números.

Lo que sí ha cambiado conviene decirlo alto: el consumo del modelo es ahora una línea real del coste. En las tarifas de la API de OpenAI, GPT-6 Astra sale a 10 $ por millón de tokens de entrada y 50 $ por millón de tokens de salida, y el modo rápido cuesta el doble. Lo que importa es cómo se multiplica: una llamada a una API consume unos cientos de tokens, mientras que un agente sobre una interfaz consume capturas y razonamiento en cada paso, y una sola tarea puede costar cientos de veces más.

De ahí dos consecuencias. El coste ya no es plano: crece con el volumen, así que pregunta por el coste estimado por ejecución, no solo por la cuota. Y el argumento anterior tiene traducción en euros: cada proceso que resuelves por API en vez de por navegador te ahorra dinero todos los meses, no solo en la implantación.

Por dónde empezar sin quemar dinero

Un proceso. El que más duele. Medido antes y después. Esa es toda la receta, y casi nadie la sigue porque es menos vistoso que un plan de veinte iniciativas. Para elegirlo, cuatro criterios a la vez:

• Ocurre mucho. Varias veces al día o decenas por semana. Sin volumen no hay retorno.
• Está escrito, o se puede escribir en una tarde. Si no cabe en una página con sus excepciones, todavía no.
• El error es barato y se deshace. Nada que mueva dinero ni firme nada en la primera iteración.
• Alguien sabe cuánto tiempo consume hoy. Si nadie lo sabe, mídelo dos semanas antes: sin línea de partida no podrás demostrar el ahorro.

Y cuatro preguntas para el equipo que te lo monte: ¿este sistema tiene API y, si la tiene, por qué proponéis manejarlo por pantalla?, ¿dónde queda registrado lo que hace el agente?, ¿qué pasa cuando falla? y ¿qué tasa de acierto habéis medido con mis datos, no con un banco de pruebas? Si alguna se responde con generalidades, no estás comprando un sistema: estás comprando una demo.

Conclusión

La novedad de 2026 no es que la IA conteste mejor, es que ejecuta trabajo sobre software real. Eso mueve la pregunta de sitio: ya no se trata de elegir modelo, sino de decidir por qué mecanismo delegas cada proceso. Si hay API, se integra por API. Si no la hay, un agente puede manejar la interfaz, pero es la puerta de servicio y se paga en fiabilidad. Si la decisión es sensible, el agente propone y una persona aprueba. Y si nadie ha escrito cómo se hace, se escribe primero.

El resto es oficio conocido: registro, reintentos, alertas, entorno de pruebas y permisos mínimos. Nada de eso sale en las demos y todo eso decide si sigues usándolo dentro de un año. Si tienes un proceso en la cabeza, cuéntanos cuál es y con qué sistemas trabaja: te decimos por qué mecanismo se resuelve, qué se queda con una persona y qué ahorro es realista. A veces la respuesta es que no compensa, y también te la vamos a dar.