¿Qué es una API key de IA y por qué no debo compartirla ni subirla a mi repositorio?

Hace unas semanas un cliente nos escribió a las once de la noche bastante nervioso: le había llegado un aviso de su proveedor de IA de que el consumo se había disparado en la última hora, algo así como doscientos dólares en cuarenta minutos. Nadie en su empresa había tocado nada. Cuando miramos el repositorio del proyecto en GitHub —público, porque lo había subido él mismo sin preguntarnos, para “enseñárselo a un socio”— ahí estaba, en un commit de hacía tres semanas, la clave de API pegada directamente en el código, sin variables de entorno ni nada. Alguien, o algún bot rastreador, la había encontrado y la estaba usando para generar quién sabe qué a su costa.

Una API key de IA es, básicamente, una contraseña que identifica tu cuenta ante el proveedor del modelo (OpenAI, Anthropic, Google o el que sea) cada vez que tu aplicación le pide algo. Si esa clave cae en manos de otra persona, esa persona puede usar el modelo como si fuera tú, y la factura te llega a ti: no hay forma de que el proveedor sepa que quien la usó no eras tú, salvo que reacciones a tiempo revocándola.

Lo que hicimos con este cliente fue lo de siempre en estos casos: revocar la clave desde el panel del proveedor en cuanto vimos el aviso, generar una nueva, y esta vez meterla en variables de entorno del servidor, nunca en el código que se sube a un repositorio. Eso llevó diez minutos. Lo que costó más fue convencerle de que su socio no necesitaba ver el código fuente para entender lo que habíamos construido —bastaba con una demo grabada— y de que un repositorio “privado pero con la clave dentro” tampoco es tan privado como parece, porque cualquier colaborador futuro, o un fork mal gestionado, la hereda igual.

La factura, por cierto, la asumió el proveedor tras una reclamación por uso fraudulento. No siempre pasa. Depende de la política de cada proveedor y de lo rápido que reportes el problema, así que no conviene contar con esa suerte.

Desde entonces aplicamos una regla en todos los proyectos que antes dábamos por sabida sin comprobarla del todo: ninguna clave va en el código, todas van en un fichero de entorno que el propio Git ignora, y las de producción se guardan aparte, en el gestor de secretos del hosting, nunca en un documento compartido por email o en un chat de WhatsApp del proyecto (nos ha pasado ver esto último más de una vez). Es la misma lección que sacamos al auditar la seguridad de nuestro propio servidor: la mayoría de sustos no vienen de un ataque sofisticado, vienen de una clave que alguien dejó a la vista sin darse cuenta.

Lo que todavía no tengo resuelto es cómo explicar esto a un cliente sin que suene a regañina, sobre todo cuando el error lo cometió alguien con buena intención que solo quería presumir de su proyecto.