Intenté que un LLM detectara sus propios errores fiscales. No puede, y resultó ser todo el negocio.
La afirmación era gramaticalmente perfecta. Ese era el problema.
Todavía recuerdo la primera posición que me hizo detenerme y dejar el café. Una IA había redactado una línea sobre la nueva deducción de intereses de préstamos de automóviles de la OBBBA, y decía: «la nueva deducción de intereses de préstamos de automóviles de la OBBBA es una deducción por encima de la línea que reduce el AGI del cliente». La frase estaba limpia. Era confiada. Estaba formateada como todas las posiciones defendibles que había leído. Y estaba equivocada exactamente de la forma que le cuesta dinero real a una persona real.
La deducción de intereses de préstamos de vehículos de pasajeros calificados (QPVLI) es una deducción por debajo de la línea conforme al §63(b)(7). No reduce el ingreso bruto ajustado. Situarla por encima de la línea no es un error ortográfico que se detecte al releer. Desplaza silenciosamente el AGI, y el AGI es el número del que depende la mitad de la declaración. Lo que me sorprendió no fue que un modelo se equivocara ligeramente con un estatuto. Fue lo bien que se veía la respuesta incorrecta.
Una cita alucinada es fácil de detectar. Una clasificación errónea confiada, escrita en inglés fiscal perfecto, es la que se presenta.
Ese fue el momento en que el problema real quedó claro para mí. La industria ha pasado tres años automatizando la redacción del trabajo fiscal, y lo hizo genuinamente bien. Thomson Reuters prepara automáticamente los 1040. CCH Axcess redacta insights de asesoría en miles de firmas. Blue J responde preguntas de investigación en lenguaje sencillo. La preparación se está resolviendo. Pero el paso después de la preparación, aquel en el que alguien tiene que decidir si la posición es realmente defendible conforme al estatuto, se entregó al mismo modelo probabilístico que la redactó. Y conforme al IRC §6662, la sanción del 20% relacionada con la exactitud recae sobre el humano que firmó la declaración, no sobre el algoritmo que la escribió.
Pasé una semana intentando que el modelo calificara su propio trabajo.
Mi primer instinto fue el obvio, y quiero ser honesto: lo perseguí más tiempo del que debí. Si el modelo puede redactar la posición, seguro que un prompt lo bastante bueno puede hacer que la revise. Así que lo intenté. Le di el estatuto. Le di la regla QPVLI explicada. Le pedí que auditara su propia salida y señalara cualquier cosa que colocara una deducción en la línea incorrecta.
Atrapó algunas. Se le escaparon otras. Y los fallos eran del tipo aterrador, porque cuando se equivocaba en la auditoría lo hacía con la misma confianza fluida que cuando redactaba. La autorrevisión pasaba por los mismos pesos que produjeron el error en primer lugar. Pedirle a un modelo que se vigile a sí mismo es pedirle a la cosa que cometió el error que también sea la que lo note, usando el razonamiento idéntico que lo provocó.
Recuerdo explicarle esto a un colega y oírme decirlo en voz alta: «no podemos confiar en que un LLM vigile a un LLM.» Esa frase fue cuando el diseño dio un vuelco para mí. Había estado intentando hacer el modelo más preciso. La respuesta real era dejar de confiar en el modelo como juez.
No se puede hacer determinista un sistema probabilístico pidiéndoselo amablemente. Se mueve el veredicto fuera de él.
La distinción que me costó demasiado interiorizar es que la redacción y la verificación no son la misma tarea hecha más fácil o más difícil. Son problemas distintos. La redacción premia la fluidez, la cobertura y la plausibilidad, exactamente para lo que está hecho un modelo de lenguaje. La verificación premia acertar de forma demostrable sobre una regla concreta, y poder mostrar el trabajo ante un examinador que no estaba en la sala. Esos son temperamentos opuestos. Dejé de intentar que un solo sistema hiciera ambas cosas.
¿Qué significa realmente «el agente aconseja, el código decide»?
Quiero ser preciso sobre la arquitectura a la que llegué, porque la frase puede sonar a marketing hasta que se ve dónde se traza la línea. En StatuteGuard, la demo que construí, el modelo de lenguaje hace exactamente un trabajo: lee lenguaje fiscal desordenado en lenguaje natural y propone una afirmación estructurada y tipada. Ese es el único paso neural. Es genuinamente bueno en eso, y cuando no está seguro, se abstiene y la posición escala a un humano en lugar de recibir un veredicto adivinado.
Todo lo que viene después es código. El veredicto lo decide un motor de políticas determinista, OPA/Rego real con un gemelo idéntico en Python puro, ejecutando reglas que escribí contra la ley primaria. Extracción neural, verificación simbólica. El modelo aconseja. El código decide. Y la diferencia no es académica, porque al código no se le puede convencer de cambiar su respuesta con un párrafo bien escrito.
La parte que no esperaba que me importara tanto como me importa es la legibilidad. Las políticas no son una caja negra en la que te pido que confíes. Son tablas de decisión y código fuente Rego que puedes abrir y contrastar tú mismo con el estatuto.
Esa captura es toda la tesis en un solo panel. Un Head of Tax debería poder sentarse con su socio de cumplimiento, abrir la regla y confirmarla contra el §30D antes de confiar en un solo veredicto. Cuando la lógica es un párrafo de razonamiento del modelo, no puedes hacerlo. Cuando es una regla que puedes leer, sí.
¿Entonces qué pasa cuando el código dice que no?
La primera vez que pasé esa posición de préstamo de automóvil de la OBBBA por el gate terminado, sonreí de verdad. El modelo había redactado la afirmación «por encima de la línea, reduce el AGI» exactamente como antes. Pero esta vez el motor determinista miró la afirmación extraída, la confrontó con la regla codificada del §63(b)(7) y devolvió un veredicto duro: BLOCK. No presentar.
Lo que me resulta persuasivo de esta vista, y lo que espero que un lector fiscal encuentre persuasivo, es la cascada. El motor no solo dice «línea incorrecta». Te muestra los cinco lugares posteriores que corrompería una falsa reducción del AGI: el ingreso bruto ajustado en sí, el impuesto estatal sobre la renta acoplado al AGI, el recargo de prima Medicare IRMAA, el piso del 7.5% de la deducción por gastos médicos y el plan de pago de préstamos estudiantiles basado en ingresos. Una deducción mal clasificada no es un solo error. Es un pequeño radio de impacto, y el panel hace visible ese radio.
Luego anima la razón, que es la pieza a la que más apegado estoy. Recorre la cadena de citas a través del grafo de referencias cruzadas del IRC, nodo a nodo, de modo que el «no» nunca sea una mera afirmación.
Aquí está el detalle al que vuelvo una y otra vez, porque es el que demuestra que esto no es un problema de juguete. Según el propio README de la demo, la etiqueta errónea «por encima de la línea» no es algo que inventé para tener un villano. Es un error de consenso documentado que la orientación general de preparación de impuestos, incluido el sitio de H&R Block, ha publicado. Una respuesta incorrecta plausible, bien escrita y ampliamente repetida es exactamente el modo de fallo para el que sirve un gate determinista. Que la multitud esté segura no hace que la deducción se mueva al AGI. El estatuto decide eso, y ahora también el código.
El error fiscal más peligroso no es el que se ve mal. Es el que se ve bien, suena bien y aparece en la orientación de tres proveedores.
Si quieres sentarte con cualquiera de esto, la demo en ejecución está en veriprajna.com/es/demos/statuteguard-verifica-posiciones-fiscales-redactadas-por-ia. Puedes pegar tu propia posición y ver cómo decide el gate.
La función que casi me equivoqué: saber cuándo decir «no lo sé»
Tengo que admitir el error que casi incorporé, porque es el que todo ingeniero que construye una herramienta de verificación quiere cometer. Mi instinto temprano fue hacer que la máquina respondiera a todo. La cobertura parecía la meta. Una herramienta que devuelve un veredicto sobre cada posición parece más terminada que una que a veces se encoje de hombros.
Ese instinto está equivocado, y una posición concreta me enseñó por qué. Considera la deducción de oficina en casa del §280A. Si un dormitorio de sobra se usa «de forma regular y exclusiva» como lugar principal de negocio es una prueba de hechos y circunstancias. No hay una regla limpia que codificar, porque la respuesta depende de cómo una persona real usa realmente una habitación real. Si obligara al motor determinista a dictaminar sobre ello, estaría haciendo exactamente lo que construí esto para impedir: fabricar un veredicto confiado donde la respuesta honesta es «un humano necesita mirar esto».
Así que el gate tiene cuatro veredictos, no dos. PASS cuando la posición es defendible. BLOCK cuando contradice el estatuto codificado. NEEDS-REVIEW cuando es una zona gris genuina. OUT-OF-COVERAGE cuando la disposición simplemente no está codificada en esta versión. Los dos últimos significan lo mismo de forma honesta: una persona decide este, no la máquina. Construir la ruta de escalamiento se sintió como admitir un límite. En realidad es la función más importante del producto, porque una capa de verificación que nunca dice «no lo sé» es solo un segundo modelo faroleando con pasos de más.
Los números, y exactamente lo que no reivindican
Soy cuidadoso con el benchmark, más cuidadoso de lo que un especialista en marketing querría que fuera, porque la forma en que suelen enunciarse estos números es una mentira. Ejecuté el motor determinista contra un conjunto dorado etiquetado de 42 posiciones preclasificadas (14 limpias, 16 con error, 12 a escalar) y medí lo que la capa hace.
En ese conjunto dorado de 42 casos: 71.4% de cobertura determinista, lo que significa que el motor resolvió esa parte a PASS o BLOCK por sí solo y escaló correctamente el resto. 100% de precisión del gate, lo que significa que cero posiciones correctas fueron bloqueadas por error. 100% de completitud de captura de errores en las disposiciones codificadas. 100% de las zonas grises escaladas correctamente. El rendimiento estuvo en decenas de miles de posiciones por segundo (unas 58,000 en la ejecución de la que tomé captura, aunque eso depende de la máquina), porque la verificación es infraestructura, no una llamada al modelo.
Ahora la parte en la que insisto. Esos números son verdaderos en ese conjunto dorado, no como garantía de mundo abierto. No te diré que StatuteGuard es «100% preciso», porque esa frase es deshonesta en el momento en que sales del conjunto etiquetado. Lo que sí te diré es más sutil y, creo, más durable: porque el veredicto es código determinista, su comportamiento en las disposiciones codificadas es reproducible y demostrable, no una probabilidad que deriva. Incluso crucé cada uno de los 42 veredictos contra OPA 1.17.1 y el gemelo en Python puro, y coincidieron exactamente. Esa es la afirmación detrás de la que puedo respaldarme. Describe la capa, no el modelo.
«100% de precisión» es un número de marketing. «Reproducible en las disposiciones codificadas, con escalamiento honesto en todas las demás partes» es uno de ingeniería. Prefiero lanzar el segundo.
Y por eso esto no caduca. Un mejor modelo base el año que viene sigue sin poder demostrar ante un examinador qué disposición estatutaria respaldó qué posición. La cobertura, la precisión del gate y una pista de auditoría presentable son propiedades de la capa de verificación. No son una tasa de error del modelo que se reduce a medida que los modelos mejoran.
El artefacto que no sabía que estaba construyendo hasta que un examinador lo pidió
No me propuse construir un documento de cumplimiento, pero cuantas más personas del área fiscal hablaba, más la conversación terminaba en el mismo lugar: «vale, atrapó el error, pero ¿qué le entrego al IRS?». Así que cada veredicto ahora escribe un registro de debida diligencia §6662 presentable, un papel de trabajo imprimible que documenta que la posición se verificó contra el estatuto antes de presentar. Papel de trabajo de origen, disposición, fuente primaria, la afirmación extraída, la narrativa de la determinación, la cadena completa de citas. Es la evidencia de que se tomó de hecho una posición de causa razonable y debido cuidado, lo que importa directamente bajo las revisiones AICPA SSTS vigentes desde enero de 2024.
Hay una razón más por la que me importa dónde corre esto, y se volvió concreta tras el fallo Heppner (SDNY, febrero de 2026), que planteó una cuestión de renuncia al privilegio sobre alimentar investigación del cliente en una herramienta de IA pública. StatuteGuard corre totalmente en local sin clave API por defecto. Ninguna posición ni datos del cliente salen del perímetro. Tras Heppner, una arquitectura cerrada, local y auditable no es solo un detalle agradable en una revisión de seguridad. Es jurídicamente material. No diseñé la postura de priorizar lo local por ese fallo. Pero el fallo es por lo que ahora lo destaco primero.
Para contextualizar lo que está en juego, los costos de cumplimiento fiscal empresarial en EE. UU. superan los $126 mil millones al año (investigación de la solución WP1, 2026), y la sanción del IRC §6662 es el 20% del pago insuficiente, con la exposición por fraude del §6663 que alcanza el 75%. Cuando la redacción está automatizada y la sanción es personal, el paso de verificación es el que debería quitarle el sueño a un Head of Tax.
Lo que realmente creo ahora
Empecé esto pensando que estaba construyendo una mejor IA fiscal, y quiero terminar diciendo claramente que me equivoqué sobre cuál era el problema. Tu IA fiscal no tiene un problema de precisión. Tiene un problema de verificación, y un mejor modelo no lo resolverá, porque la sanción del 20% recae sobre tu firma, no sobre sus pesos. Personalizar y automatizar la redacción del trabajo fiscal es un progreso real. Tampoco es lo mismo que demostrar que una posición es defendible, y la industria ha estado tratándolos en silencio como si lo fueran.
La demo vive en veriprajna.com/es/demos/statuteguard-verifica-posiciones-fiscales-redactadas-por-ia si quieres intentar romper el gate. Me gustaría de verdad que lo hicieras.
Y si prefieres ver cómo decide el gate a leerme describirlo, aquí está todo el proceso de extremo a extremo.
Así que esta es la pregunta que sigo haciendo a los líderes fiscales, y aún no tengo una respuesta cómoda. Cuando una IA redacta una posición y tú firmas la declaración, ¿cuál es el artefacto que demuestra que tú la verificaste, en lugar de confiar en ella? Si la respuesta honesta es «nada, confié en el modelo», entonces el modelo no es tu asistente. Es tu cofirmante, y no se le puede citar a la auditoría.
