Cómo Deel eliminó 900 horas de ingeniería dedicadas a apagar incendios con un sistema de IA de 4 agentes

Escalar la nómina parece sencillo en teoría. Contratas más rápido, sincronizas más registros y mantienes el cumplimiento. Pero si la tasa de fallas se mantiene aproximadamente constante mientras tu volumen crece, el número absoluto de fallas aumenta al mismo ritmo de tus contrataciones. Si tu equipo de ingeniería no crece con ello, de pronto estás dedicando más tiempo a investigar fallas y menos a construir lo que realmente importa.

En Deel, procesamos nómina PEO en EE. UU. para miles de nuevas contrataciones de forma continua, y cuando una sincronización falla, hay un nuevo contratado esperando su primer pago. Eso hizo que nuestro antiguo proceso de triaje fuera imposible de ignorar, no por las métricas de eficiencia, sino por lo que realmente nos estaba costando.

El verdadero costo de apagar incendios

Una sincronización de nómina falla y un ingeniero deja su trabajo en el sprint para investigar. Lo que ocurre a continuación es el patrón que seguíamos viendo repetirse: abren cuatro herramientas simultáneamente: nuestro sistema de nómina, la base de datos de registros de contratación, los registros de errores y las reglas de cumplimiento laboral, y pasan los siguientes 45 minutos reconstruyendo qué salió mal al cruzar mensajes de error y estados del sistema entre todas ellas.

Un pico de fallas, que no era raro durante los momentos de contratación intensa, podía consumir el día entero de un equipo de ingeniería investigando. Estábamos destinando nuestro recurso más caro al trabajo de menor valor.

Al analizarlo, vimos que alrededor del 55 % de las fallas eran transitorias: bloqueos de base de datos durante ventanas de alta escritura, condiciones de carrera al finalizar registros de contratación y problemas de sincronización que se resolvían por sí solos. Las condiciones que las causaban ya no existían cuando alguien las revisaba. Sin un sistema que haga seguimiento de los resultados en cada caso, ese patrón era invisible. Cada falla parecía un problema único que valía la pena investigar, ya que ninguna se anunciaba como "reinténtame".

Podríamos haber añadido reintentos con backoff antes, pero no puedes lanzar un reintento con confianza sobre un registro de nómina sin saber primero si la falla es transitoria o estructural. Si es estructural, un reintento puede agravar el problema, así que el diagnóstico tiene que ocurrir de cualquier manera. Lo que cambió con el agente es que ambas cosas pasan en segundos en lugar de que una requiera 45 minutos.

Lo que construimos

En lugar de centrarnos en cómo investigar fallas más rápido, empezamos a preguntarnos cómo evitar la investigación por completo. Desplegamos una canalización de cuatro etapas en Akai, la plataforma interna de orquestación de IA de Deel, donde cada etapa se encarga de una tarea específica y hace una entrega limpia a la siguiente sin intervención manual ni necesidad de que un ingeniero la active.

Etapa 1: Detección y agrupamiento

Cada pocos minutos esta etapa se despierta, escanea el sistema de nómina en busca de sincronizaciones fallidas, las deduplica y agrupa fallas relacionadas antes de entregar un lote limpio hacia abajo en la cadena, todo sin requerir un ping en Slack ni un disparador humano.

Etapa 2: Reintento e investigación

Esta etapa ejecuta un reintento automático en cada falla y, aproximadamente en el 55 % de los casos, eso es todo: el error transitorio se limpia por sí solo y no hace falta investigar. Para el 45 % restante, se expande en paralelo para comprobar el estado del registro de contratación, extraer logs de los sistemas de monitorización, consultar la base de datos de nómina y cruzar las reglas de cumplimiento, todo al mismo tiempo. Ninguna de esas operaciones se bloquea entre sí, por eso el diagnóstico tarda menos de 10 segundos aunque toque cuatro sistemas distintos.

Etapa 3: Clasificación y remediación

Esta etapa traduce el ruido del sistema en significado real al categorizar la falla—SSN duplicado, dirección inválida, estado de declaración de impuestos faltante, datos de enrutamiento erróneos, entre otros—y luego hace lo que antes consumía la mayor parte del tiempo de un ingeniero: determina de quién es realmente el problema (empleador, empleado o Deel) y escribe el comando exacto necesario para arreglarlo.

Etapa 4: Entrega

La etapa final empaqueta todo en Slack con una sección por falla, comandos listos para copiar y pegar y enlaces directos a logs, y además analiza los casos para reconocer cuándo el mismo error se repite entre varias contrataciones de la misma empresa, presentándolo como un único problema de configuración a nivel empleador en lugar de inundar al equipo con diez alertas individuales.

El problema de 45 minutos que nos negamos a aceptar

Los números hablan por sí mismos:

Los ingenieros no desaparecieron del circuito, pero el dolor de cabeza sí. Alrededor del 55 % de los casos ahora se resuelven solos sin que nadie los toque, y el resto sigue llegando a un ingeniero. Sin embargo, ahora llegan como una revisión de 30 segundos en lugar de una investigación de 45 minutos, lo que significa que el ingeniero sabe exactamente qué está fallando y qué hay que hacer a continuación.

Cómo lo hacemos

Esto no es exclusivo de Deel, y la arquitectura no es novedosa. Se aplica a cualquier desafío de triaje de infraestructura que puedas tener. Esto es lo que realmente hizo que funcionara para nosotros:

Etapas secuenciales con operaciones en paralelo dentro de cada una. Cada etapa se ejecuta después de que la anterior termina, pero la ganancia crítica de rendimiento ocurre dentro de la etapa de investigación, donde todas las búsquedas de datos se disparan al mismo tiempo; así nada se bloquea entre sí, y esa es la diferencia entre una operación de 40 segundos y una de 10 segundos.

Taxonomía de fallas específica. La etapa de clasificación tiene una taxonomía estructurada de tipos de falla, y lo hermoso de este enfoque es que añadir una nueva categoría de falla cuando aparece algo en producción es solo un cambio de una línea en el prompt.

Transferencias limpias en JSON entre etapas. Cada etapa recibe JSON limpio, hace su trabajo y devuelve JSON limpio, lo que significa que no hay estado compartido ni dependencias misteriosas.

Reintento inmediato como predeterminado. La mayoría de las fallas son transitorias, así que la lógica es simple: reintenta de inmediato, mide qué porcentaje se resuelve solo y luego investiga lo que queda.

Más allá de la nómina

La nómina es nuestro caso de uso, pero el patrón se puede aplicar en cualquier lugar donde la infraestructura sea ruidosa: fallas de API, incidentes de bases de datos, errores del proveedor cloud o escalaciones de soporte al cliente en las que hay alto volumen, señal enterrada en ruido y necesitas separar lo que puede arreglarse automáticamente de lo que realmente requiere intervención humana. Aunque las herramientas específicas cambien, la lógica es la misma: reintentar, diagnosticar, clasificar, enrutar.

La mayoría de las organizaciones enrutaban todo a humanos y esperaba que lo resolvieran, y eso funciona hasta que contratas rápido y el volumen abruma al equipo. Automatiza lo que puedas y reserva el juicio humano para lo que no puedas automatizar.

Cómo ayuda Deel

La plataforma de Deel gestiona la complejidad de la nómina para que tus ingenieros no tengan que invertir su tiempo en investigarla. Lo hacemos mediante flujos de trabajo orquestados por IA que gestionan el trabajo de alto volumen y baja señal. Tus ingenieros pueden enfocarse en lo que realmente los necesita: añadir resiliencia al sistema y asegurarse de que estas fallas no ocurran en primer lugar, en lugar de pasar los días apagando incendios.

Agenda tu demo de Deel, y descubre cómo es escalar la nómina global sin los dolores de cabeza.