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 ofrece una vía de integración se usa esa vía; si solo queda la interfaz, primero se comprueba si basta una automatización determinista; y el agente que interpreta la pantalla queda para cuando la tarea exige criterio, no como novedad que hay que comprar.

Quédate con tres ideas: la decisión es el mecanismo, no el modelo, un agente de navegador va después de la integración y de la automatización determinista 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 el subconjunto offline de OSWorld 2.0, un banco de pruebas de tareas reales sobre un escritorio, alcanza un 72,6% de puntuación parcial 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 matiz que casi nadie cita: puntuación parcial no es tarea completada

Aquí es donde la mayoría de artículos miran hacia otro lado. La tabla de OpenAI etiqueta ese 72,6% como puntuación parcial, no como porcentaje de tareas completadas: reconoce el avance dentro de una tarea aunque el resultado entero no esté terminado. Por tanto, no permite convertir el resto hasta cien en una tasa de fallo. Sí permite decir dos cosas: que mejora al modelo anterior bajo esa misma medida y que un resultado de laboratorio no acredita que el agente complete de principio a fin tu proceso real.

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 esos límites, 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 resultado 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. Las tasas no dicen cuántos usuarios hay en cada departamento ni qué capacidad técnica tienen; sí muestran que el uso ya crece mucho más deprisa fuera de ingeniería. Y eso abre un problema de gobierno: los equipos que adoptan la herramienta no siempre son los que pueden integrarla, limitar sus permisos y mantenerla.

Cuando esa brecha no se gestiona aparecen dos riesgos. 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? Después de descartar APIs, webhooks, acceso a datos e intercambio de ficheros. Si solo queda la interfaz y los pasos son fijos, un script o un RPA determinista suele ser más predecible. El agente con computer use entra cuando, además, cada caso exige leer, interpretar o adaptarse: un portal de un tercero con documentos distintos, una intranet heredada o un ERP antiguo sin otra vía. Pregunta siempre qué alternativas de integración existen y por qué hace falta razonamiento sobre la pantalla: si la respuesta es solo que el agente puede hacer clic, 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 una vía de integración, se conecta y se orquesta. API, webhook, base de datos o ficheros: 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 vía de integración y el proceso exige interpretar. El backoffice es el caso típico: facturas, albaranes y partes de trabajo que llegan en formatos distintos y hay que introducir en un ERP que no expone nada. Si los pasos son siempre iguales basta una automatización determinista; cuando cambian el documento o la pantalla, el agente con computer use puede resolver esa variación, 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, y los avisos concretos que tienes que poner, en el artículo 50 del AI Act.
• 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 la ficha oficial de GPT-6 Astra, la entrada cuesta 10 $ por millón de tokens y la salida, 50 $; 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 una vía de integración, se usa. Si solo queda la interfaz y los pasos son fijos, se automatiza de forma determinista. Si además hace falta interpretar cada caso, un agente puede manejarla, pero se paga en coste y 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.