Tecnología · July 21, 2026 · 9 min de lectura

Ingeniería de prompts para analistas de datos: desconfía del número

La ingeniería de prompts para analistas de datos es una definición precisa de la métrica más la disciplina de desconfiar del resultado hasta que cuadre. Por qué el número es el riesgo.

← Parte de Evaluaciones generadas por IA: la guía completa de 2026

Para un analista de datos, el resultado de una sesión de IA es un número, y ese número se pega en una presentación y se convierte en una decisión. Eso eleva las apuestas de la ingeniería de prompts para analistas de datos de una forma específica: el modo de fallo no es código feo, es una cifra plausible que silenciosamente no cuadra. Si contratas analistas, esta es la habilidad que decide si una consulta generada por IA ahorra una tarde o publica un hecho incorrecto ante el consejo. Esta es la entrada de analistas en nuestra serie de ingeniería de prompts por rol, y es una de las cosas más claras que el AI Sandbox revela sobre el juicio real de un candidato.

Por qué las apuestas son diferentes para los analistas

El error de IA de un ingeniero suele anunciarse: el build falla, una prueba falla, el linter se queja. El error de un analista hace lo contrario. Una consulta que doble-cuenta los reembolsos devuelve un número limpio y convincente, con el formato correcto, en las unidades correctas. Nada en él parece mal. Fluye hacia un panel de control, luego hacia una diapositiva, luego hacia una conversación estratégica, y el error solo se detecta si alguien lo concilia contra una cifra en la que ya confía. Esa asimetría es la razón por la que la ingeniería de prompts importa más, no menos, una vez que un analista tiene herramientas de IA a mano. La herramienta reduce el coste de producir una respuesta a casi cero mientras deja el coste de una respuesta incorrecta exactamente donde estaba.

Así que la habilidad que vale la pena contratar no es la fluidez con una ventana de chat. Es el hábito de tratar cada cifra generada por IA como una afirmación que tiene que ganarse la confianza. Ese hábito es indistinguible de una buena práctica analítica; la IA simplemente ha hecho más fácil saltárselo. Los analistas que prosperan son los que se niegan a saltarlo.

El número sobrevive a la consulta

Considera lo que ocurre después de que el analista cierra el portátil. El SQL se descarta, pero el número no. Se convierte en una línea en un informe para el consejo, un objetivo en un OKR, un umbral en una regla de alertas. Seis semanas después nadie recuerda qué definición de ingresos netos lo produjo, y la consulta que resolvería la discusión hace tiempo que desapareció. Por eso la disciplina del analista no puede ser un hábito privado ejercido en el momento; tiene que ser el tipo de hábito que deja un rastro. Establecer la definición en el prompt, pedir al modelo que registre sus supuestos y conciliar antes de publicar son formas de hacer que el razonamiento sea duradero. Cuando contratas a un analista, en realidad estás contratando la durabilidad de los números que dejará atrás.

Un buen prompt es una definición precisa

Reducir las alucinaciones en el trabajo analítico se reduce a especificidad y límites, no a redacción ingeniosa. Una petición vaga, «dame ingresos por mes», invita al modelo a elegir una definición por ti, y elegirá una plausiblemente incorrecta cada vez que haya ambigüedad. Un analista sólido escribe la métrica, las exclusiones y la fuente de verdad en el prompt, y le da al modelo permiso explícito para rechazar en lugar de adivinar. Eso es AI Fluency en el puesto de un analista: el prompt y el rigor analítico son el mismo acto. No estás escribiendo instrucciones para una máquina tanto como forzándote a establecer, de forma completa, lo que realmente quieres decir con el número que estás a punto de reportar.

Las definiciones son el trabajo real

Toda disputa analítica es una disputa definitorial disfrazada de numérica. ¿Una cuenta dada de baja es la que canceló, la que dejó de pagar, o la que cayó por debajo de un umbral de uso? ¿«Usuario activo» significa que inició sesión, realizó una acción, o realizó una acción significativa? La IA no puede resolver esto por ti, y cuando lo dejas sin especificar lo resuelve en silencio. Poner la definición en el prompt no es burocracia; es el momento en que descubres que tú y tu stakeholder quisieron decir dos cosas distintas todo el tiempo.

Un ejemplo trabajado

Pide ingresos netos por mes. La versión débil se detiene ahí. La versión sólida define «neto», nombra las exclusiones, especifica qué marca de tiempo cuenta como el mes, y le dice al modelo que señale todo lo que no pueda encontrar en lugar de inventar un nombre de columna. Luego, la parte que realmente importa: el analista verifica el resultado contra una cifra en la que ya confía antes de que salga de su pantalla.

## TASK
Write SQL: net revenue by calendar month for 2025.

## DEFINITIONS
- net revenue = gross - refunds
- Exclude internal test accounts (email domain @acme-internal.com)
- "Month" = orders.completed_at, not created_at

## RULES
- If a column I named does not exist, tell me. Do not guess a name.
- Return the query, then list every assumption you made

• Bueno: especifica la métrica, las exclusiones y la fuente de verdad; pide los supuestos; verifica el resultado; desconfía de un número que los datos no respaldan.
• Débil: acepta una consulta plausible, reporta una cifra que silenciosamente doble-cuenta los reembolsos, y nunca lo nota hasta que alguien más adelante sí lo hace.

Dónde pone el analista sólido su atención

Observa a un analista sólido trabajar una tarea de IA y los momentos interesantes no son cuando escribe el prompt. Son cuando hace una pausa en el resultado. El resultado llega, la consulta parece ordenada, y en lugar de copiar la cifra se detiene y pregunta si es aproximadamente del tamaño que esperaba. Un número que es un orden de magnitud demasiado grande se detecta en esa pausa; también uno que es sospechosamente redondo, o que se movió en la dirección incorrecta respecto al trimestre anterior. Aquí es donde el conocimiento de dominio y AI Fluency se fusionan. La herramienta produjo la respuesta, pero solo un analista que ya lleva un modelo aproximado del negocio en la cabeza sabe cuándo desconfiar de ella. El prompt plantea la pregunta; el escepticismo decide si se permite que la respuesta salga de la sala.

También es donde los analistas junior y senior divergen más visiblemente. Un analista junior tiende a confiar en una consulta limpia porque se ejecutó sin error. Un senior trata «se ejecutó» y «es correcta» como afirmaciones completamente distintas, y pone su atención en la segunda. La IA ha ampliado esa brecha, porque hace que producir una consulta limpia pero incorrecta sea effortless mientras no hace nada en absoluto para ayudarte a notar que es incorrecta.

Mejores prácticas que realmente marcan la diferencia

• Define antes de preguntar. Pon la definición de la métrica, las exclusiones y el grano temporal en el prompt. La ambigüedad es donde nacen los números incorrectos, y el prompt es donde la resuelves o se la entregas al modelo para que la resuelva mal.
• Da permiso para decir «no sé». Dile al modelo que responda con «datos insuficientes» o «esa columna no existe» en lugar de adivinar. Alucina mucho menos cuando el rechazo es una respuesta permitida.
• Pide los supuestos. Pídele que liste lo que asumió. Ahí es donde detectarás la definición mal leída antes de que se convierta en una cifra reportada.
• Verifica cada resultado contra un número en el que ya confíes. Una cifra que no cuadra es el hallazgo, no un error de redondeo que hay que suavizar.
• Mantén una fuente de verdad. Nombra la tabla, vista o capa de métricas canónica en el prompt para que el modelo no sea libre de unirse a lo que parezca conveniente.

Modos de fallo habituales

• Métrica vaga: «ingresos» sin definición, así que el modelo elige una silenciosamente y heredas su elección sin saber que la tomaste.
• Confiar en el número porque la consulta parece limpia. SQL limpio sobre una definición incorrecta sigue siendo una respuesta incorrecta, y el código limpio es exactamente lo que lo hace peligroso.
• Nunca conciliar contra una cifra de confianza conocida, así que el error se publica como hecho y solo sale a la luz cuando las tripas de un stakeholder discrepan con la diapositiva.
• Dejar que el modelo invente una columna o un join que no puede verificar, y luego reportar sobre datos que no significan lo que el analista asume que significan.

Ninguno de estos es exótico. Son las formas ordinarias en que el análisis siempre ha salido mal, aceleradas. La diferencia es la velocidad: una herramienta de IA puede generar una respuesta plausiblemente incorrecta en segundos, así que la única salvaguarda restante es la disciplina del analista para desconfiar de ella. Esa disciplina no es un rasgo de personalidad que se puede cribar en una conversación de entrevista. Es un hábito de trabajo, y la única forma honesta de observar un hábito de trabajo es observar el trabajo.

El prompt es donde ocurre la conversación con el stakeholder

Hay un segundo beneficio más silencioso de escribir definiciones en el prompt: obliga a la conversación con el stakeholder que debería haber ocurrido de todas formas. Cuando un product manager pide «conversión por canal este trimestre», el analista que simplemente reenvía eso a una herramienta de IA se ha saltado el paso más importante. ¿Qué evento de conversión cuenta? ¿«Este trimestre» significa el fiscal o el natural? ¿Un canal es el primer contacto o el último? Escribir el prompt es el momento en que esas preguntas se vuelven inevitables, porque el modelo necesita una respuesta y el analista tiene que proporcionarla. Un buen analista toma eso como un aviso para volver atrás y preguntar, no para adivinar en nombre del solicitante.

Por eso los analistas más sólidos a menudo producen el prompt y las preguntas aclaratorias al mismo tiempo. La especificación que entregan al modelo es, casi palabra por palabra, la especificación que deberían confirmar con la persona que pidió el análisis. La herramienta ha convertido silenciosamente un paso que la gente solía saltarse en uno que no puede, siempre que se tome en serio la redacción en lugar de pegar la solicitud verbatim. Un candidato que reflexivamente acota una petición ambigua antes de tocar los datos te está mostrando exactamente el instinto que evita que se generen números incorrectos en primer lugar.

AI Fluency es un pilar, no un complemento

En nuestro modelo de cinco pilares, AI Fluency se sitúa junto a la capacidad cognitiva, de dominio, el juicio situacional y el conductual, en lugar de reemplazar a ninguno de ellos. Para un analista esto importa porque AI Fluency sin juicio de dominio es peor que inútil: produce respuestas incorrectas más rápido y con más confianza. El analista que detecta el reembolso doble-contado lo hace porque ya sabe aproximadamente cuál debería ser el ingreso neto. La herramienta no le dio ese instinto; hizo que tenerlo fuera más valioso. Por eso tratamos esto como AI Fluency evaluado como un pilar distinto, puntuado por encima de las habilidades de dominio que un buen analista ya necesita, nunca en su lugar.

Cómo lo evaluamos

No puedes evaluar esto con un cuestionario de trivia sobre prompts, y no puedes evaluarlo quitando la IA, lo que simplemente mide una tarea que nadie hace de esa forma ya. Das al candidato una tarea de análisis realista con herramientas disponibles y observas si define la métrica, detecta el agregado engañoso y respalda un número que realmente se sostiene: exactamente lo que hace una evaluación en AI Sandbox. Consulta qué cubre una evaluación completa de analista de datos, cómo difiere el rol hermano para ingenieros de software, y por qué esta es la prueba honesta en la contratación AI-native.

Los mejores analistas tratan la respuesta de la IA como cualquier número sorprendente: culpable hasta conciliar. Ese instinto, no la redacción del prompt, es lo que mantiene un número incorrecto fuera de la sala del consejo.