Cuando el One Big Beautiful Bill llegó como un documento no estructurado de 900 páginas (sin un esquema estandarizado, sin formularios del IRS publicados y con una fecha límite de envío estricta), el equipo TurboTax de Intuit se hizo una pregunta: ¿Podría la IA comprimir una implementación de meses en unos pocos días sin sacrificar la precisión?
Lo que han construido para lograr esto es menos una historia fiscal y más un modelo, un flujo de trabajo que combina herramientas comerciales de inteligencia artificial, un lenguaje propietario específico de dominio y un marco de prueba unitario personalizado del que cualquier equipo de desarrollo con dominio restringido puede aprender.
Joy Shaw, directora de Impuestos de Intuit, ha pasado más de 30 años en la empresa y ha vivido tanto la Ley de Empleos y Reducción de Impuestos como la OBBB. «Hubo mucho ruido en la propia ley y pudimos extraer de ella las implicaciones fiscales, reducirlas a las disposiciones fiscales individuales y a nuestros clientes», dijo Shaw a VentureBeat. «Este tipo de destilación fue muy rápido con las herramientas y luego nos permitió comenzar a codificar incluso antes de recibir los formularios y las instrucciones».
Cómo OBBB subió el listón
Cuando se aprobó la Ley de Empleos y Reducción de Impuestos en 2017, el equipo de TurboTax trabajó en la legislación sin la ayuda de la IA. Fueron necesarios meses y las exigencias de precisión no dejaron lugar a atajos.
“Antes, teníamos que revisar la ley y codificar las secciones que hacían referencia a otras secciones del código de la ley y tratar de resolverlo por nuestra cuenta”, dijo Shaw.
El OBBB llegó con los mismos requisitos de precisión pero con un perfil diferente. Con más de 900 páginas, era estructuralmente más complejo que la TCJA. Era un documento desestructurado, sin un esquema estandarizado. Las versiones de la Cámara y el Senado utilizaron un lenguaje diferente para describir las mismas disposiciones. Y el equipo tuvo que comenzar la implementación antes de que el IRS emitiera formularios o instrucciones oficiales.
La pregunta era si las herramientas de inteligencia artificial podrían comprimir la línea de tiempo sin comprometer el resultado. La respuesta requirió una secuencia específica y herramientas que aún no existían.
Del documento no estructurado al código específico de dominio
La OBBB aún estaba siendo aprobada en el Congreso cuando el equipo de TurboTax comenzó a trabajar en ella. Utilizando modelos de lenguaje grandes, el equipo resumió la versión de la Cámara, luego la versión del Senado y luego concilió las diferencias. Ambas cámaras hicieron referencia a las mismas secciones subyacentes del código tributario, un ancla consistente que permitió a los modelos hacer comparaciones entre documentos estructuralmente inconsistentes.
El día de la firma, el equipo ya había filtrado las provisiones para aquellas que afectan a los clientes de TurboTax, limitándolas a situaciones fiscales y perfiles de clientes específicos. El análisis, conciliación y filtrado de provisiones pasó de semanas a horas.
Estas tareas fueron manejadas por ChatGPT y LLM de propósito general. Pero estas herramientas alcanzaron un límite cuando el trabajo pasó del análisis a la implementación. TurboTax no se ejecuta en un lenguaje de programación estándar. Su motor de cálculo de impuestos se basa en un lenguaje propietario específico de dominio mantenido internamente en Intuit. Cualquier modelo que genere código para esta base de código debe traducir el texto legal a una sintaxis en la que nunca fue entrenado e identificar cómo las nuevas disposiciones interactúan con décadas de código existente sin romper lo que ya funciona.
Claude se convirtió en la herramienta principal para este trabajo de traducción y mapeo de dependencias. Shaw dijo que puede identificar qué ha cambiado y qué no, permitiendo a los desarrolladores centrarse únicamente en los nuevos arreglos. «Es capaz de integrarse con cosas que no cambian e identificar dependencias de lo que ha cambiado», dijo. «Esto aceleró el proceso de desarrollo y nos permitió centrarnos sólo en las cosas que cambiaron».
Construir herramientas adaptadas a un umbral de error cercano a cero
Los LLM de propósito general permitieron al equipo trabajar en código. Para que este código se pueda enviar, se requieren dos herramientas patentadas creadas durante el ciclo OBBB.
El primer producto TurboTax generado automáticamente filtra directamente los cambios legislativos. Anteriormente, los desarrolladores organizaban estas pantallas individualmente para cada diseño. La nueva herramienta manejó la mayoría automáticamente, con personalización manual solo cuando fue necesario.
El segundo fue un marco de prueba unitario especialmente diseñado. Intuit siempre había realizado pruebas automatizadas, pero el sistema anterior solo producía resultados de pasa/falla. Cuando fallaba una prueba, los desarrolladores tenían que abrir manualmente el archivo de datos de la declaración de impuestos subyacente para rastrear la causa. «La automatización le indicaría si aprueba o no, y tendría que revisar el archivo de datos tributarios para ver qué pudo haber salido mal», dijo Shaw. El nuevo marco identifica el segmento de código específico responsable, genera una explicación y permite que la corrección se realice dentro del propio marco.
Shaw dijo que la precisión de un producto de impuestos al consumidor debe ser cercana al 100 por ciento. Sarah Aerni, vicepresidenta de tecnología de Intuit para Consumer Group, dijo que la arquitectura debe producir resultados deterministas. «Tener el tipo de capacidades en torno al determinismo y correcciones verificables mediante pruebas, eso es lo que conduce a ese tipo de confianza», dijo Aerni.
Las herramientas gestionan la velocidad. Pero Intuit también utiliza herramientas de evaluación basadas en LLM para validar los resultados generados por IA, e incluso estos requieren que un profesional de impuestos humano evalúe si el resultado es correcto. «Se trata de tener experiencia humana para poder validar y verificar casi cualquier cosa», dijo Aerni.
Cuatro componentes que cualquier equipo industrial regulado puede utilizar
OBBB era una cuestión fiscal, pero las condiciones subyacentes no son exclusivas de la fiscalidad. Los equipos de atención médica, servicios financieros, tecnología legal y adquisiciones públicas se enfrentan regularmente a la misma combinación: documentos regulatorios complejos, plazos estrictos, bases de código patentadas y tolerancia a errores casi nula.
Según la implementación de Intuit, cuatro elementos del flujo de trabajo son transferibles a otros entornos de desarrollo restringidos por dominio:
-
Utilice LLM comerciales para el análisis de documentos. Los modelos de propósito general manejan bien el análisis de acumulación, la conciliación y el filtrado. Aquí es donde añaden velocidad sin crear riesgo de precisión.
-
Cambie a herramientas específicas de dominio cuando el análisis esté operativo. Los modelos de propósito general que generan código en un entorno propietario sin comprenderlo producirán resultados en los que no se puede confiar a escala.
-
Construya una infraestructura de prueba antes de la fecha límite, no durante el sprint. Las pruebas automatizadas genéricas producen resultados de pasa/falla. Las herramientas de prueba de dominios específicos que identifican fallas y permiten correcciones en contexto son las que hacen que el código generado por IA se pueda distribuir.
-
Implemente herramientas de IA en toda la organización, no solo en ingeniería. Shaw dijo que Intuit entrenó y supervisó el uso de todas las funciones. El dominio de la IA se distribuyó por toda la organización en lugar de concentrarse entre los primeros usuarios.
«Seguimos explotando las oportunidades que ofrecen la IA y la inteligencia humana, para que nuestros clientes obtengan lo que necesitan a través de las experiencias que creamos», afirmó Aerni.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.













































































