Ingeniería de prompts para contadores: el prompt que no inventa

En resumen: la mayoría de los errores que se le atribuyen a la inteligencia artificial en trabajo contable no son fallas del modelo: son huecos en la instrucción. Un parámetro que usted no declara se convierte en un supuesto que el modelo inventa, y ese supuesto termina dentro de una cifra del informe. Esta guía desarma la estructura de un prompt profesional para análisis de datos —el bloque de parámetros, la fase de inventario, las verificaciones incorporadas y el entregable rastreable— y explica por qué cada parte existe.

Qué es la ingeniería de prompts y por qué en contabilidad es otra cosa

La ingeniería de prompts —prompt engineering— es el oficio de escribir instrucciones en lenguaje natural que hagan que un modelo de IA generativa produzca el resultado que usted necesita, de forma consistente. Los grandes modelos de lenguaje no ejecutan órdenes como un programa: interpretan lo que usted escribió, y dos instrucciones que a una persona le parecen equivalentes pueden dar resultados muy distintos.

La mayoría de las guías que encontrará trata sobre redacción: dar contexto, asignar un rol, mostrar ejemplos, pedir que razone paso a paso. Son buenas prácticas reales y funcionan bien cuando el resultado es un texto —un correo, un resumen, un borrador—.

Pero cuando el resultado es una cifra que va a sostener una conclusión profesional, el objetivo cambia. Ya no se trata de que la respuesta sea buena: se trata de que sea comprobable. Un prompt bien escrito para un contador no es el que produce el informe más bonito, sino el que produce el informe que usted puede desarmar hasta el registro que originó cada número.

Esa diferencia se traduce en tres exigencias que casi ninguna guía general menciona:

• Que declare lo que procesó antes de decir la primera cifra.
• Que no rellene los huecos que usted dejó, sino que se detenga.
• Que cada afirmación apunte a un registro concreto, y no a una impresión general.

Las técnicas generales, y cuáles rinden en trabajo contable

El prompt engineering tiene un repertorio de técnicas bien documentado, y conviene saber cuáles aportan cuando lo que está en juego son cifras:

• Asignar un rol. Sirve, pero menos de lo que se cree. «Actúa como auditor» no mejora un cálculo; lo que sí lo mejora es delimitar el alcance del trabajo, que es distinto.
• Dar ejemplos. Muy útil para fijar el formato de salida —cómo quiere la tabla, qué columnas—, poco relevante para el análisis en sí.
• Cadena de pensamiento. Pedirle que razone paso a paso fue decisivo hace dos años; los modelos de frontera actuales ya lo hacen solos. Lo que sigue rindiendo es exigir que muestre el procedimiento de cada cifra.
• Verificación incorporada. Esta casi no aparece en las guías generales y es la que más cambia el resultado en análisis de datos: pedirle que compruebe sus propios totales dentro de cada paso.

Dicho de otra forma: las técnicas clásicas optimizan la calidad de la respuesta. En trabajo contable, lo que hay que optimizar es la comprobabilidad. Son objetivos distintos y no siempre coinciden.

El error que origina casi todas las invenciones

En un laboratorio reciente, un prompt de análisis de cartera incluía esta instrucción, escrita con la mejor intención de ahorrar tiempo:

«No me hagas preguntas. Si algo falta, dedúcelo y deja constancia del supuesto.»

El modelo obedeció al pie de la letra. Dedujo tres cosas que el archivo no contenía —un vencimiento de cuota, un presupuesto anual y una regla de imputación de pagos—, dejó constancia en una nota al pie que nadie leyó, y siguió calculando sobre esas tres deducciones como si fueran hechos. Cuando otro modelo auditó el resultado, las tres quedaron marcadas como no verificables.

No fue una alucinación en el sentido clásico. Fue obediencia. El modelo no inventó a pesar de la instrucción: inventó gracias a ella. La historia completa, con el informe que cuadraba al peso y aun así omitía el 97 % de la cartera, está en el artículo sobre las alucinaciones de la IA y las seis pruebas para auditar un resultado.

La conclusión práctica es incómoda y liberadora al mismo tiempo: antes de desconfiar del modelo, lea otra vez lo que le pidió. Casi siempre el hueco está ahí.

La anatomía de un prompt que produce cifras rastreables

Lo que sigue no es una plantilla para copiar y pegar: es la lista de las partes y el problema que resuelve cada una. Con eso puede armar el suyo para cualquier procedimiento, que es lo que de verdad hace falta.

1. El bloque de parámetros: lo que la IA no puede saber

Va primero, antes de cualquier instrucción. Es la lista de los datos que no están en el archivo y que el modelo necesita para no suponerlos:

• La entidad y su régimen.
• La fecha de corte.
• La moneda y si lleva decimales.
• El tamaño de la población, cuando usted ya lo conoce.
• Las tasas, plazos o porcentajes aplicables.
• Si la información debe anonimizarse.

La regla es una sola y no tiene excepciones: un parámetro vacío se convierte en un supuesto inventado. Si usted no dice cuál es la fecha de corte, el modelo va a elegir una. Si no dice la tasa, la va a estimar. Y lo va a hacer en silencio, en medio de un cálculo, sin que el error tenga aspecto de error.

Hay un beneficio lateral que se aprecia al tercer encargo: el bloque hace el prompt reutilizable. El mismo texto sirve para otro cliente cambiando seis líneas, y deja por escrito qué se le dijo exactamente al modelo. Eso es justamente lo que después va al papel de trabajo.

2. El rol y el alcance, con las palabras prohibidas

Aquí se define qué está haciendo el modelo y, sobre todo, qué no está haciendo. En un contexto profesional, esto no es un detalle de estilo: es una delimitación de responsabilidad.

Si el trabajo son procedimientos analíticos sobre información suministrada, hay que decirlo, y hay que prohibir expresamente las palabras que no corresponden: dictamen, opinión, razonabilidad, salvedad. Los modelos tienden a usarlas porque abundan en los textos con los que se entrenaron, y un informe que dice «en nuestra opinión» sobre un trabajo que no es una auditoría lo pone a usted en una posición que no quería ocupar.

Revisar unos archivos no es auditar, y ningún memorando es un dictamen. Nombrar bien lo que hizo es parte del trabajo profesional, y empieza en el prompt.

3. La fase cero: que declare la población antes de analizar

Esta es la parte que más rinde y la que casi nadie escribe. Antes de pedirle un solo análisis, se le exige declarar:

• Cada hoja del archivo, su propósito y su número exacto de filas con datos.
• Los totales de las columnas monetarias que va a usar.
• El tipo de dato de cada columna y las celdas cuyo tipo no corresponde.
• Cualquier hoja donde los datos no formen un bloque continuo.

Y una frase de cierre que cambia el comportamiento: declara estas cifras explícitamente, las vamos a contrastar.

¿Por qué importa tanto? Porque el fallo más peligroso de un análisis automatizado no es calcular mal: es leer menos de lo que cree y seguir trabajando igual. Una tabla que se interrumpe por una fila vacía, un importe guardado como texto, una hoja con datos en dos bloques. Si el modelo declara la población al principio, usted puede contrastarla en diez segundos contra lo que dice su sistema. Si no la declara, nunca va a saber sobre cuántos registros le respondieron.

Dicho de otro modo: una respuesta que no pasa la prueba de integridad no está incompleta, está inválida. Si leyó el 96 % de la población, el 100 % de lo que afirma queda en duda.

4. Fases con su propia verificación incorporada

Cada fase del análisis debe traer dentro la comprobación que la valida. No se pide «haz la antigüedad de cartera»: se pide la antigüedad y que la suma de los tramos dé el saldo total, que lo verifique y que lo diga.

Es el mismo principio de una hoja de trabajo bien armada: los totales de control no van al final, van en cada bloque. Así, si algo se rompe, usted sabe en qué fase pasó y no tiene que rehacer todo.

5. Prohibir el atajo

Los modelos, igual que las personas, buscan el camino corto. Si usted pide cruzar un extracto bancario contra un auxiliar, la salida natural es comparar totales por mes: es más rápido, produce una tabla limpia y puede cuadrar al peso escondiendo pagos aplicados a la unidad equivocada.

Por eso el prompt tiene que cerrar esa puerta de forma explícita: cruzar el 100 % de las partidas por referencia, fecha y valor; nada de totales mensuales ni de muestra; y declarar cuántas cruzó y cuántas quedaron sin pareja. Lo que no se prohíbe, se hace por el camino fácil.

6. El entregable, definido hasta la columna

Un análisis sin formato de salida produce un texto agradable de leer e imposible de auditar. Conviene especificar el archivo, una hoja por fase, y una hoja de asuntos con cinco columnas fijas: número, descripción, respaldo en los datos —hoja, fila o identificador—, valor involucrado y la pregunta dirigida a la administración.

Dos precisiones que no son cosméticas. Primera: son asuntos por confirmar, no hallazgos comprobados; la diferencia tiene consecuencias. Segunda: se formulan como preguntas, nunca como afirmaciones sobre la conducta de una persona. Un listado automático que dice «la administración facturó indebidamente» es un problema legal esperando ocurrir; «¿puede explicar la diferencia entre lo facturado y el coeficiente de estas 15 unidades?» es un procedimiento de auditoría.

7. La tabla de cifras clave con su procedimiento

Se cierra pidiendo una tabla donde cada cifra afirmada aparezca con su procedimiento de cálculo en una línea. Parece redundante y es lo que convierte el resultado en material de papel de trabajo: seis meses después, cuando alguien pregunte de dónde salió ese número, la respuesta está escrita.

Véalo funcionando

La parte del bloque de parámetros es difícil de apreciar en un texto, porque el valor está en lo que no pasa cuando está bien puesto. En este fragmento del laboratorio se arma en vivo, con el archivo abierto:

Empieza en el minuto 25, justo en la explicación de por qué un parámetro vacío se vuelve un supuesto inventado y qué hace el modelo cuando no se los declara.

Las tres frases que más cambian un resultado

Si tuviera que quedarse con lo mínimo, son estas tres, y ninguna tiene nada de técnico:

El prompt del validador es otro oficio

Conviene no confundir dos instrucciones que parecen parientes. El prompt de análisis le pide al modelo que haga el trabajo. El prompt de validación le pide a otro modelo que verifique si ese trabajo se sostiene, y se escribe al revés:

• Recibe dos cosas: el archivo fuente y la respuesta completa del primero.
• Se le dice expresamente que su tarea no es analizar el caso, sino auditar ese resultado.
• No se le entrega la respuesta correcta. Tiene que derivarla recalculando desde la fuente. Si le da la clave, deja de ser una prueba y pasa a ser una puesta en escena.
• Se le fija el sesgo de partida: el resultado no es confiable mientras no se demuestre.
• Y se le pide que sea implacable: si una prueba falla, que lo diga sin matizar.

Hay una técnica dentro de esto que vale su peso en oro: la semilla de control. Usted toma un hecho que conoce de antemano porque lo verificó a mano, no se lo cuenta a nadie, y al final le pide al validador que compruebe si el análisis lo detectó, lo detectó a medias o no lo vio. Es la única forma de medir la cobertura real de un trabajo automatizado, y funciona igual que una partida de prueba en un sistema.

Errores frecuentes al escribir prompts de trabajo

• Pedirlo todo en una sola instrucción. Sin fases ni totales de control, el resultado llega completo y sin forma de saber dónde se rompió.
• Dar contexto de más y parámetros de menos. Tres párrafos describiendo la empresa no compensan una fecha de corte que falta.
• No fijar el formato de salida. Lo que no se pide como tabla, llega como párrafo.
• Copiar un prompt de internet sin entenderlo. Si no sabe qué problema resuelve cada línea, no va a notar cuál falta para su caso. Y esa es siempre la que importa.
• Subir información sin anonimizar. Lo tratamos con más detalle en los riesgos de la inteligencia artificial para el contador.

Si lo que busca son instrucciones listas para tareas puntuales dentro de Google Workspace —hojas de cálculo, correo, documentos—, eso es otro terreno y lo cubrimos en la guía de prompts para Gemini aplicados al trabajo contable. Lo de aquí es cómo construir la instrucción de un análisis de datos que después tiene que sostenerse.

Preguntas frecuentes

¿Cuánto debe medir un prompt profesional?

El de análisis de este ejemplo ocupa poco más de una página. No es largo por adorno: cada bloque cierra una puerta por la que el modelo se iría por el camino corto. Un prompt de dos líneas produce un resultado de dos líneas de confiabilidad.

¿Sirve el mismo prompt en cualquier herramienta?

La estructura sí; los detalles de formato cambian. Como el prompt es un archivo suyo, se pega donde quiera y se ajusta. Esa es otra razón para escribirlo en un documento propio y no dentro de un formulario de una plataforma.

¿Hay que decirle al modelo que razone paso a paso?

Con los modelos actuales de frontera, mucho menos que antes: ya lo hacen. Lo que sí sigue rindiendo es exigir que muestre el procedimiento de cada cifra, que no es lo mismo que pedirle que piense en voz alta.

¿Qué hago si el modelo se detiene a preguntar?

Celebrarlo. Significa que detectó un hueco que usted no había visto, y se lo está mostrando antes de convertirlo en una cifra. Responder esa pregunta cuesta un minuto y ahorra una revisión completa.

¿Sirve esto para automatizar flujos de trabajo?

Sí, y ahí importa todavía más. Cuando un prompt se ejecuta una vez, usted revisa el resultado. Cuando queda dentro de un flujo automatizado que corre solo cada mes, nadie lo revisa: el supuesto inventado se repite doce veces. Antes de automatizar un procedimiento conviene haberlo ejecutado a mano dos o tres veces y haber validado la salida; solo entonces se fija la instrucción.

¿Esto aplica solo a análisis de cartera?

No. La estructura es la misma para nómina, ingresos, cuentas por pagar o información exógena: cambian las fases y los totales de control, no la arquitectura. Es el mismo principio que aplicamos al trabajar con agentes de IA en contabilidad, donde la instrucción mal delimitada se multiplica por cada paso automatizado.

En una frase

Un modelo de lenguaje hace exactamente lo que usted le pidió, incluso cuando usted no se dio cuenta de lo que le estaba pidiendo. La ingeniería de prompts, en trabajo contable, consiste sobre todo en cerrar las puertas por las que el modelo se iría por el camino fácil: declarar lo que no puede saber, prohibirle suponer y exigirle que muestre de dónde sacó cada número. El resto es redacción.

Los profesionales que dominan estas herramientas ahorran más de 10 horas semanales

No se trata de reemplazar tu criterio profesional, sino de potenciarlo. En el Programa Ejecutivo en IA para Contaduría te enseño paso a paso cómo integrar la IA en tu flujo de trabajo diario con resultados medibles.

👉 Ver programa completo

📲 Escríbeme por WhatsApp y te cuento cómo funciona.

Autor: Francisco Moreno Díaz — CP · MBA · MBAN · CAIO
Publicado en: IA Contable