Hace unos años arrastro una pregunta que me da vueltas: ¿el mercado le cobra más barato el capital a las empresas que gestionan mejor sus riesgos no financieros? Y una segunda, que me interesa más: si eso pasa, ¿pasa en todos los mercados o depende de que haya instituciones que auditen y penalicen?
En 2025 armé una exploración empírica para mirarlo: empresas del MERVAL contra empresas del S&P 100, código en Python escrito con asistencia de IA. Salió un documento largo, con tablas, coeficientes y p-valores. Los resultados daban lo que la teoría predecía.
Hace unos días volví a abrir el código para retomarlo. Encontré cuatro errores. Dos de ellos, cada uno por su cuenta, invalidan todo el resultado.
Escribo esto porque los cuatro son errores genéricos: no tienen nada que ver con ESG, y son especialmente fáciles de cometer cuando el código lo escribe una IA y uno lo lee por encima. Ninguno de los cuatro rompe el programa. Los cuatro producen salidas prolijas.
Error 1: la variable dependiente era, en realidad, otra variable
Yo creía estar midiendo el costo de capital (WACC). El código hacía esto:
cost_of_equity = risk_free_rate + beta * market_premium
wacc = cost_of_equity
Dos problemas encimados. El primero es que ahí no hay WACC: no hay deuda, ni estructura de capital, ni impuestos. Es costo de equity por CAPM, que es otra cosa.
El segundo es más grave. risk_free_rate y market_premium estaban fijos como constantes. Si esos dos números no varían entre empresas, entonces wacc = a + b × beta es una transformación lineal del beta. Es el beta, con otra escala y otro nombre.
Así que todo lo que yo presentaba como "ESG contra costo de capital" era, literalmente, ESG contra beta de mercado. No es una aproximación imperfecta: es otra pregunta.
Si tu variable dependiente se construye a partir de otra variable con constantes fijas, no es una variable nueva. Y si además incluís esa otra variable como control en la regresión, estás poniendo la misma información de los dos lados de la ecuación.
Error 2: datos simulados que garantizan el resultado
Para las empresas argentinas no había calificaciones ESG de ningún proveedor comercial. La solución que quedó en el código fue esta:
np.random.seed(42)
analysis_data['ESG_Score'] = np.random.randint(40, 86, size=len(analysis_data))
Números aleatorios entre 40 y 85.
Estaba documentado como "prueba de concepto", y en el texto largo figuraba como limitación. Pero acá está la trampa que no vi en su momento: el hallazgo era que Argentina no mostraba relación significativa. Y una regresión contra ruido aleatorio va a dar exactamente eso, siempre. No es un resultado que se descubre: es el resultado que la construcción obliga.
Peor: yo usaba ese no-hallazgo como la mitad del argumento. La comparación era "en Estados Unidos sí, en Argentina no, entonces las instituciones importan". Pero la mitad argentina de esa comparación no medía nada.
Cuando trabajás con datos sintéticos, preguntate qué resultado están forzando. Un dato simulado sin estructura no puede producir un hallazgo negativo — solo puede producir ausencia de señal, que es lo mismo que decir nada.
Error 3: la escala apuntaba para el otro lado
La variable ESG de Estados Unidos venía de yfinance, del campo totalEsg. Yo la trataba como un puntaje de desempeño: más alto, mejor gestión ESG.
totalEsg es un Sustainalytics ESG Risk Rating. Mide riesgo. Más alto es peor.
Con la escala invertida, mi coeficiente negativo significativo —que yo leía como "mejor ESG, menor costo de capital"— dice en realidad lo contrario.
Lo que más me llamó la atención al revisarlo es que el dato para darme cuenta estaba en mis propias tablas. Las descriptivas mostraban media 28,45, mínimo 8,20 y máximo 52,70. Si fuera un puntaje de bondad sobre 100, ninguna empresa del S&P 100 sacaría 8,20, y el máximo no se cortaría en 52,70. Ese rango es exactamente el de un rating de riesgo. Lo tuve delante todo el tiempo.
Antes de interpretar el signo de un coeficiente, leé la documentación de la escala. Y si no la tenés a mano, mirá el rango de tus propios datos: te dice qué tipo de métrica es.
Error 4: los números publicados no salían del código
Este es el que más me incomoda. El documento reportaba un panel con efectos fijos de empresa y de tiempo, cuatro variables de control, n=312 y n=92.
Los scripts que existen corren una regresión de corte transversal, una fila por empresa, sin efectos fijos, sin controles, sin rezagos, con n=23 del lado argentino. Y las salidas guardadas de esa corrida daban R²=0,045 y p=0,333 — no los valores del documento.
En algún punto entre correr el análisis y escribir el texto, las tablas se volvieron más sofisticadas que el análisis. No hay mala fe: hay un documento largo, escrito con asistencia, que describe el estudio que uno quería hacer en vez del que efectivamente corrió.
Todo número de un informe tiene que poder rastrearse hasta la línea de código que lo produjo. Si no podés reproducirlo hoy, no lo publiques.
El patrón
Los cuatro errores comparten algo: ninguno rompe nada. El código corre, no tira excepciones, las tablas salen formateadas, los p-valores caen en rangos plausibles. Nada en la pantalla te avisa.
Esto se volvió más importante, no menos, desde que programamos con IA. Un asistente escribe código que funciona con una facilidad enorme, y "que funcione" y "que sea correcto" son cosas distintas. La IA no sabe que tu market_premium fijo convirtió tu variable dependiente en otra cosa: para ella, es una línea válida.
La checklist que me quedó
Cinco preguntas, antes de creerle a un resultado propio:
- ¿Mi variable dependiente es realmente lo que digo que es? Rastrearla hasta cómo se construye, no hasta cómo se llama.
- ¿Alguna constante fija convierte una variable en transformación de otra?
- ¿Hay datos simulados o imputados? ¿Qué resultado fuerza esa construcción?
- ¿En qué dirección va cada escala? Verificar contra la documentación de la fuente, y contra el rango observado.
- ¿Puedo reproducir hoy, corriendo el código, cada número del informe?
Por qué publico esto
Porque la pregunta me sigue interesando y la voy a rehacer bien. Y porque un error metodológico explicado sirve más que un resultado que no se sostiene.
La investigación queda publicada como lo que es: una búsqueda personal en curso, sin resultados. La pregunta sigue abierta, el marco teórico y el diseño comparativo se sostienen, y para que haya un hallazgo hacen falta tres cosas que hoy no tengo: datos ESG reales para los dos mercados en la misma escala y dirección, un WACC construido de verdad, y un panel que exista como panel.
Si estás haciendo algo parecido y ves algo que se me sigue escapando, escribime.