Un asiento que no sabes explicar no está contabilizado.

El sistema propone una cuenta y un importe. Encaja. El balance cuadra y nadie tiene que tocar nada. Y aun así, si dentro de dos años alguien pregunta por qué ese gasto acabó ahí y no en la cuenta de al lado, la respuesta no puede ser que lo propuso el programa.

Trabajo con asuntos donde equivocarse cuesta dinero. No me interesa si la herramienta es impresionante. Me interesa qué queda encima de la mesa el día que el resultado se discute.

Qué cambia de verdad cuando metes IA en contabilidad

Cambia el punto de entrada del trabajo. Antes alguien miraba un documento y decidía. Ahora alguien mira una propuesta ya formada y decide si la acepta. Parece el mismo trabajo con menos pasos, y no lo es.

Aceptar una propuesta cuesta menos que construirla. Ahí está toda la ganancia de velocidad y también todo el riesgo. Una propuesta bien presentada arrastra al que la revisa hacia el sí, porque discrepar obliga a justificarse y aceptar no obliga a nada.

Lo segundo que cambia es la forma del error. Una persona que clasifica mal un gasto se equivoca de manera desordenada. Un sistema que clasifica mal lo hace igual mil veces, con la misma lógica y la misma seguridad. El error deja de ser un incidente y se convierte en un patrón, y los patrones se detectan tarde precisamente porque son consistentes.

Una propuesta de la máquina pesa lo que pesa un borrador de becario

Con una diferencia importante: el becario duda. Escribe un correo preguntando o deja una nota al margen del documento. Esa duda es información valiosa y no cuesta nada.

La máquina no duda de forma útil. Puede enseñarte un porcentaje de confianza, pero ese número describe su propia coherencia interna, no si el criterio aguanta en este caso concreto. Un documento ambiguo puede producir una propuesta segurísima y equivocada, y nada en la pantalla la distingue de una correcta.

Por eso yo trataría cada propuesta automática como lo que es. Trabajo hecho deprisa por alguien que no conoce al cliente. Se revisa igual. Lo que no haría es revisarlo con menos atención por venir de una pantalla más cara.

El tiempo no se ahorra: se muda de sitio

Aquí está la parte que ningún folleto cuenta. La captura de datos sí ahorra tiempo real, y bastante. Teclear un documento no aporta criterio y nadie va a echar de menos esa tarea.

Lo que no ahorra tiempo es la clasificación con matiz. Ahí el trabajo se desplaza de producir a comprobar, y comprobar cuesta lo que cuesta hacerlo bien. Si lo haces bien, el ahorro es más pequeño de lo que prometía la demostración. Si lo haces mal, el ahorro parece enorme hasta el día en que aparece la primera consecuencia.

Mi forma de medirlo sería aburrida. Cronometrar el proceso completo durante un mes, incluyendo lo que se tarda en detectar y arreglar lo que salió torcido. No el tiempo de la propuesta, que siempre es espectacular, sino el tiempo hasta que el trabajo está cerrado y alguien lo firmaría sin releerlo.

Quién responde cuando la cuenta la firma un profesional

Respuesta corta: el profesional que firma.

No conozco ningún contrato de software que traslade la responsabilidad profesional al proveedor, y sería sorprendente que lo hubiera. Las condiciones suelen decir justo lo contrario con bastante claridad. La herramienta asiste y el usuario decide. Esa frase parece relleno jurídico hasta el día en que hay una discrepancia y alguien la lee en voz alta. Ese es el peor momento posible para leerla por primera vez.

El sistema que actúa solo concentra el riesgo donde nadie mira

Hay una distancia grande entre una herramienta que propone y otra que registra directamente. La segunda se vende como el paso natural de la primera. No lo es. Es un cambio de naturaleza, porque cuando algo queda contabilizado sin que nadie lo mire, el control ha dejado de existir aunque la pantalla conserve un botón de revisar.

La guía de OWASP sobre agencia excesiva describe ese patrón con detalle Fuente primaria ↗. Yo separaría desde el primer día lo que el sistema puede leer de lo que puede escribir. Y trataría el envío de información fuera del despacho como un permiso aparte, que se concede solo cuando hace falta.

Añadiría una precaución que en contabilidad casi nadie se plantea. Una factura es texto redactado por un tercero, y el sistema la lee sin desconfianza ninguna. El contenido de un documento que entra no debería poder cambiar el comportamiento de la herramienta que lo procesa, un riesgo que OWASP tiene descrito desde hace tiempo Fuente primaria ↗.

Qué documentación conservaría para reconstruir un criterio

La pregunta útil no es cuánto guardar. Es qué tendrás que poder contestar dentro de dos años sobre un asiento concreto que hoy te parece evidente.

Con eso claro, hace falta menos de lo que parece. Basta con poder enseñar qué documento se tuvo delante y qué propuso el sistema antes de que nadie lo corrigiera. Cuando la propuesta se cambió, dos líneas explicando el motivo valen más que cualquier registro automático de actividad.

Guardarlo todo tampoco es la solución contraria. Un archivo que acumula cada movimiento genera información que después hay que proteger y justificar durante años. El marco de gestión de riesgos del NIST insiste en la proporcionalidad de las medidas respecto al riesgo del uso concreto Fuente primaria ↗, y esa proporción vale igual para la evidencia que decides conservar.

Qué le preguntaría a quien vende automatización contable

Empezaría por el fallo y no por la función. Qué ocurre cuando llega un documento que no encaja con ningún patrón conocido. Si el sistema se detiene o si elige lo más parecido y sigue adelante. Esa respuesta separa a un proveedor que ha pensado en tu riesgo de uno que solo ha pensado en su demostración.

Después preguntaría por el histórico. Si el criterio de clasificación cambia con una actualización, qué pasa con todo lo que se registró antes bajo el criterio anterior. Hay herramientas que contestan bien a esto. Otras descubren la pregunta en la reunión.

Y pediría probarlo con documentos inventados y feos. No con la factura limpia del ejemplo, sino con la que llega mal escaneada y con un concepto que no dice absolutamente nada. Es un ensayo sintético, sin un solo dato de cliente, y aun así enseña más que una hora de presentación.

Un «esto no lo hacemos» dicho de frente me tranquiliza bastante más que un «se adapta a cualquier caso». Lo que se compra es una capacidad delimitada, no una promesa sin bordes.

Lo que sigue siendo tuyo aunque compres la mejor herramienta

La explicación. Un asiento no vale por estar puesto, vale por poder sostenerse cuando alguien de fuera pregunta. Esa parte no la automatiza nadie, entre otras cosas porque quien pregunta no quiere hablar con el software.

Automatizaría sin miedo lo que es mecánico y se comprueba rápido. Y no dejaría que la velocidad de la propuesta decidiera cuánto tiempo dedico a mirarla.

Un asiento que no sabes explicar no está contabilizado. Está apuntado.

Lo que me preguntan cuando cierro el portátil.

¿Puede la IA llevar la contabilidad de una empresa?

Puede hacer buena parte del trabajo mecánico: leer un documento y proponer un registro con los datos que extrae de él. Lo que no puede es decidir cuándo un caso se aparta del patrón habitual, porque para eso hace falta conocer al cliente y recordar qué se acordó en ejercicios anteriores. La propuesta llega hecha, la decisión sigue siendo de alguien.

¿Quién responde si un asiento propuesto por una IA está mal?

El profesional que lo acepta y lo firma. Las condiciones de uso del software suelen decirlo con bastante claridad, y conviene leerlas antes de contratar. El proveedor asume el funcionamiento de su herramienta dentro de los límites que él mismo define. La responsabilidad profesional no viaja con la licencia.

¿Qué conviene guardar cuando se usa IA en contabilidad?

Lo suficiente para reconstruir por qué algo se registró de una manera concreta. Eso significa poder enseñar qué documento se tuvo delante y qué propuso el sistema antes de que nadie lo corrigiera. Cuando la propuesta se cambió, dos líneas con el motivo valen más que un registro automático de actividad que solo dice que alguien pasó por ahí.

El expediente detrás del artículo.

LLM06:2025 · Agencia excesiva ↗OWASP GenAI Security Project · 2025
Guía técnica de riesgosLLM01:2025 · Prompt injection ↗OWASP GenAI Security Project · 2025
Guía técnica de riesgosPerfil de riesgos de IA generativa ↗NIST · AI 600-1 · 2024
Marco técnico voluntario

Fuentes consultadas el 9 de septiembre de 2026. Las recomendaciones y ejemplos son elaboración editorial: no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.

Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.