La inteligencia artificial ya dejó de ser el «juguete nuevo» para convertirse en una herramienta de uso cotidiano para quienes trabajamos con datos. Ya sea que necesitemos una consulta en SQL medio complicada, una transformación en Python o un análisis exploratorio, la IA nos lo entrega en cuestión de segundos. El problema es que la calidad de ese entregable depende en gran medida de cómo formulamos el pedido.
La IA rara vez admite que no puede responder adecuadamente a un prompt. Tampoco cuestiona la calidad o la facilidad de comprensión de los prompts que le enviamos. En vez de eso, siempre nos da alguna respuesta, aunque la pregunta sea confusa o esté mal formulada. Esa respuesta será código y análisis elegantes, código que funciona, pero que posiblemente no haga las cosas bien.
Puede ocurrir que arrastre supuestos incorrectos, que incluya joins dudosos o que haga interpretaciones débiles, todo lo cual incrementará la necesidad de validación de los resultados. Con un prompt adecuado y bien pensado, no eliminaremos la fase de validación, pero reduciremos mucho el esfuerzo requerido para asegurar la fiabilidad de los resultados.
Este artículo forma parte de la serie sobre ciencia de datos en la era de la IA. Aquí nos enfocamos en una habilidad práctica: cómo obtener de la IA mejores análisis y mejor código, constituyendo un complemento para el artículo sobre cómo validar el trabajo de la IA.
Por qué el prompt engineering es tan importante
Pedirle a una IA que escriba un texto creativo y pedirle que calcule una métrica de negocio son cosas muy diferentes. En análisis de datos, los errores suelen ser silenciosos; puede ser que el código no arroje errores, que los números parezcan plausibles, pero que todo eso esté lisa y llanamente mal.
El prompt engineering aplicado a la ciencia de datos busca reducir esos riesgos desde el origen. Spoiler: no hay palabras o frases mágicas; la clave está en dar contexto y en aplicar restricciones y criterios claros para que la IA produzca algo más robusto, explícito y fácilmente revisable.
Principios básicos para prompts de datos
Antes de ver patrones concretos, tengamos presentes algunos principios que funcionan de forma transversal a toda tarea de prompt engineering:
1. Ampliar el contexto
No debemos asumir que la IA conoce nuestras tablas, nuestras reglas de negocio o el significado de cada campo/columna de nuestros esquemas. Cuanto más claro y abarcativo sea el escenario que le damos a la IA para trabajar, mejores serán los resultados obtenidos.
2. Definir un rol
Es conveniente indicarle a la IA qué rol debe asumir. Podemos pedirle que actúe como analista de datos senior, como ingeniero de datos o como científico de datos. Esto suele mejorar el nivel de rigor y el estilo de las respuestas que nos da.
3. Especificar el formato de salida
Antes de promptear nada, pensemos: ¿cómo necesitamos ver los resultados? Decidamos si queremos ver sólo el código, el código más una explicación en «prosa» de su funcionamiento, una lista de supuestos, o pasos numerados para ejecutar un proceso. Lo que sea que necesitemos, se lo debemos especificar claramente a la IA para evitar que nos dé respuestas difusas o que nos devuelva más o menos de lo que necesitamos.
4. Restringir el alcance
Debemos indicar con qué librería trabajamos (Pandas o Polars), qué dialecto de SQL usamos, cuál es nuestro estilo de código preferido o qué limitaciones debemos tener en cuenta. Si no especificamos las restricciones de alcance a las que debemos someternos, la IA irá por su cuenta y probablemente nos dé resultados incompatibles con nuestro entorno o con nuestras herramientas.
5. Pedir supuestos explícitos
Una de las mejores prácticas del prompting consiste en pedirle a la IA que nos indique con exactitud cuáles son los supuestos que está asumiendo. Esto se logra con una simple orden: “Declara qué estás asumiendo”. De esta forma, tendremos visibilidad sobre muchas decisiones que de otra forma permanecerían ocultas.
6. Iterar
Rara vez el mejor resultado sale en el primer intento. Siempre podemos usar la respuesta anterior como base y pedir ajustes, correcciones o alternativas.
Publicidad
Patrones de prompts útiles
A continuación veremos algunos patrones que suelen dar buenos resultados en prompt engineering de ciencia de datos para distintos propósitos específicos: código SQL, código Python (Pandas/Polars), análisis exploratorio, validación/control de calidad y justificación de resultados.
Para SQL
Un prompt efectivo para obtener código SQL suele incluir:
- el objetivo de negocio
- las tablas y campos relevantes
- reglas importantes (filtros, definiciones, exclusiones)
- el formato de salida deseado
- pedido de explicación o validaciones
Estructura recomendada:
Actúa como un analista de datos senior.
Quiero [objetivo].
Tablas disponibles: [listado breve].
Reglas de negocio: [condiciones].
Devuélveme solo la consulta SQL y, después, una breve explicación de los joins y filtros.
Declara cualquier supuesto que estés haciendo.
También es útil pedir:
- una versión alternativa
- chequeos de calidad (duplicados, nulos, cardinalidad)
- que evite subconsultas innecesarias o que priorice legibilidad
Actúa como un analista de datos senior.
Quiero el total de ventas y la cantidad de pedidos por cliente durante 2025.
Tablas disponibles:
- customers (customer_id, customer_name, country)
- orders (order_id, customer_id, order_date, amount, status)
Reglas de negocio:
- Considera solo pedidos con status = 'completed'
- Un cliente puede tener múltiples pedidos
- El total debe ser la suma de amount
Devuélveme:
1. La consulta SQL
2. Una breve explicación de los joins y filtros
3. Los supuestos que estés teniendo en cuenta/code>Para Python (Pandas / Polars)
En Python conviene ser explícito con la librería y con el estilo.
Estructura recomendada:
Actúa como un científico de datos.
Usa [Pandas/Polars].
Objetivo: [transformación o análisis].
El DataFrame se llama df y tiene las columnas [listado].
Devuélveme código limpio y reproducible, con pasos claros.
Maneja nulos y declara supuestos.
Pedidos que suelen mejorar el resultado:
- que separe carga, limpieza, transformación y resultado
- que evite encadenamientos difíciles de depurar
- que incluya comentarios mínimos solo donde aporten claridad
Actúa como un científico de datos.
Usa Polars.
Objetivo: calcular el ingreso mensual y la cantidad de clientes activos por mes.
El DataFrame se llama df y tiene estas columnas:
- customer_id
- order_date
- amount
- status
Reglas:
- Filtra solo status = "completed"
- Agrupa por mes
- El código tiene que ser limpio, reproducible y fácil de seguir
- Maneja nulos si aparecen
Devuélveme el código y declara cualquier supuesto.Para análisis exploratorio (EDA, exploratory data analysis)
Cuando prompteamos para análisis exploratorio, el valor no está solo en el código, sino en las preguntas que la IA puede ayudar a formular.
Ejemplo de enfoque:
Tienes un dataset de [descripción].
Propone un análisis exploratorio:
- preguntas clave que habría que responder
- métricas y desgloses relevantes
- posibles anomalías a revisar
- visualizaciones sugeridas y qué mirar en ellas
No inventes hallazgos; trabaja a nivel de plan de análisis.
Este tipo de prompt es especialmente útil antes de ponerse a codear.
Actúa como un analista de datos senior.
Tengo un dataset de pedidos online con estas columnas:
customer_id, order_date, amount, status, country, channel.
Todavía no quiero código. Quiero un plan de análisis exploratorio.
Incluye:
1. Preguntas clave que habría que responder
2. Métricas y desgloses más relevantes
3. Posibles anomalías o problemas de calidad de datos a revisar
4. Visualizaciones sugeridas y qué mirar en cada una
No inventes hallazgos. Trabaja a nivel de plan, no de conclusiones.Para validación y control de calidad
La IA también puede ayudarnos a revisar y validar tanto su propio trabajo como el nuestro.
Ejemplos de pedidos útiles:
- “Revisa este código y señala posibles errores lógicos, data leakage o supuestos peligrosos.”
- “Propone 3 tests simples o assertions para validar el resultado.”
- “¿Qué casos límite podrían romper esta consulta?”
Estos prompts no reemplazan la validación humana, pero aceleran la detección de problemas.
Actúa como un revisor senior de análisis de datos.
Te paso este código SQL/Python generado para calcular [métrica].
Quiero que lo valides. Señala:
1. Posibles errores lógicos
2. Riesgo de data leakage o de usar información que no correspondería
3. Supuestos ocultos
4. Casos borde que podrían romper el resultado
5. 3 tests simples o assertions para verificar que el cálculo esté bien
No reescribas todo el código salvo que sea necesario para mostrar el problema.Para explicación de resultados
Debemos pedirle que separe niveles de lectura:
- Lo que muestran los datos
- La interpretación
- Las limitaciones o cuidados
Esto evita que mezcle hallazgos con conclusiones demasiado fuertes.
Actúa como un analista de datos que tiene que explicar resultados a un equipo de negocio.
A partir de este resultado:
[pegar tabla, métrica o hallazgo]
Separa claramente:
1. Qué muestran los datos
2. Qué interpretación es razonable
3. Qué limitaciones o cuidados hay que tener
4. Qué no se puede afirmar todavía
Evita mezclar hallazgos con recomendaciones. Si hay correlación, no la presentes como causalidad.Errores comunes al promptear análisis de datos
Los siguientes son algunos de los errores más frecuentes en prompt engineering para análisis de datos:
- Pedir de forma demasiado vaga, como por ejemplo: “Analiza este CSV” o “Dame un SQL de ventas”.
- No informar el esquema ni las reglas de negocio.
- No especificar librería o dialecto SQL.
- Aceptar la primera respuesta sin pedir supuestos ni alternativas.
- No solicitar manejo de nulos, duplicados o casos borde.
- Confundir “el código corre” con “el análisis está bien”.
La mayoría de estos errores se corrigen con prompts más contextuales y con una ronda de refinamiento.
Publicidad
Ejemplos prácticos: antes y después
Ejemplo 1 – SQL
Prompt débil:
Dame el total de ventas por cliente.
Prompt fuerte:
Actuá como analista de datos senior.
Quiero el total de ventas por cliente usando las tablas customers y orders.
Un cliente puede tener múltiples órdenes.
Considerá solo órdenes con status = 'completed'.
Devuélveme la consulta SQL y una breve explicación del join.
Declara supuestos.
La segunda versión reduce la ambigüedad y suele producir una solución más defendible.
Ejemplo 2 – Python
Prompt débil:
Normaliza las variables numéricas y separa train/test.
Prompt fuerte:
Usa scikit-learn.
Separa primero en train y test (80/20, random_state=42).
Después aplica StandardScaler: fit solo en train y transform en train y test.
Devuélveme el código y explica por qué este orden evita data leakage.
Este tipo de precisión evita uno de los errores más comunes en preprocesamiento.
Buenos prompts + validación
Las buenas prácticas de prompt engineering mejoran la calidad de lo que recibimos de una IA cuando prompteamos para tareas de ciencia de datos. Luego, la validación asegura que aquello que recibimos realmente sirve.
En la práctica, el flujo más sólido suele ser:
- Pedir con buen contexto y restricciones.
- Revisar la lógica y los supuestos.
- Probar con datos controlados.
- Contrastar con un enfoque alternativo.
- Recién entonces: comunicar resultados.
La IA puede ayudar en varias de estas etapas, pero la responsabilidad final sigue siendo humana. Cuanto mejor sea el prompt, menos fricción habrá en la validación. Cuanto mejor sea la validación, más confiable será el entregable.
Una habilidad práctica clave que seguirá siendo humana
El prompt engineering para ciencia de datos no es una disciplina abstracta. Es una habilidad práctica que se desarrolla pidiendo mejor, refinando y contrastando.
No se trata de tener buenos modales o de hablarle “bonito” a la IA, sino de darle el contexto, las restricciones y los criterios que un colega senior necesitaría para hacer bien el trabajo. Y, al mismo tiempo, de mantener el hábito de validar todo lo que nos devuelve. Pensemos que, aunque le pidamos que actúe como un analista senior, los errores que comete pueden parecer propios del junior menos experimentado.
Mejorando la forma de pedir y sosteniendo un proceso claro de validación, la IA deja de ser una fuente de respuestas rápidas para convertirse en una herramienta con mucho potencial para mejorar nuestro trabajo.
Este artículo se apoya en el marco general de ciencia de datos en la era de la IA y se complementa con la guía sobre cómo validar el trabajo de la IA en análisis de datos.
¿Qué es el prompt engineering en ciencia de datos?
Es la práctica de formular instrucciones claras y contextualizadas para que la IA genere mejor código, mejores análisis y resultados más fáciles de validar.
¿Por qué no alcanza con pedir “dame un SQL” o “analiza este dataset”?
Porque sin contexto, reglas de negocio y formato de salida, la IA completa los vacíos con supuestos que pueden ser incorrectos y difíciles de detectar.
¿Cuáles son los elementos que componen un buen prompt para análisis de datos?
Contexto de los datos, objetivo claro, rol (por ejemplo, analista senior), formato de salida, restricciones técnicas y pedido de supuestos explícitos.
¿El prompt engineering reemplaza la validación del trabajo de la IA?
No. Un buen prompt mejora la calidad del punto de partida, pero la validación sigue siendo necesaria para detectar errores lógicos, data leakage y conclusiones flojas.
¿Se puede usar la IA también para validar su propio código?
Sí. Se le puede pedir que revise posibles errores, proponga pruebas simples, señale supuestos peligrosos o sugiera casos borde. Eso no reemplaza el criterio humano, pero sí ayuda.
