Saltar al contenido

Claves API de IA: una alerta no evita la factura sorpresa

Guardar bien la clave es solo una parte. Aprende a distinguir una alerta de un corte real y comprueba qué frena el gasto, quién recibe el aviso y cómo sigue funcionando tu web.

Llave formada por caracteres luminosos que se fragmenta en código y símbolos de euro sobre un fondo ciberpunk azul y magenta.
Ciberseguridad / Blog Dreamsite

Compartir

Tu web tiene un chatbot que utiliza una API de inteligencia artificial. Configuras un aviso para cuando su consumo alcance 100 euros al mes. Pero ese aviso no bloquea las consultas: el gasto puede seguir creciendo.

Una clave API es la credencial con la que una aplicación se identifica ante un proveedor de IA. Si alguien la copia, puede usar los servicios que permita esa clave con cargo a tu cuenta. Para reducir el riesgo necesitas protegerla, limitar el consumo y comprobar que el corte funciona. Aquí tienes qué revisar en OpenAI, Claude y Gemini, además de una prueba y una ficha que puedes pasar a quien mantenga tu aplicación.

Alerta, límite de gasto y límite de velocidad: qué hace cada uno

  • La alerta avisa. Envía una notificación al alcanzar un umbral; por sí sola no bloquea nuevas peticiones.
  • El límite de gasto corta el acceso según el consumo contabilizado. Su alcance depende del proveedor, del proyecto y del servicio. No lo confundas con un importe garantizado al céntimo.
  • El límite de velocidad reduce el ritmo. Restringe peticiones o tokens por minuto. Los tokens son las unidades con las que el modelo procesa texto; no equivalen siempre a palabras. Este límite no sustituye a un presupuesto mensual.

Para una aplicación de empresa, combina los tres. El aviso permite actuar antes del corte; el límite de velocidad contiene los picos; el de gasto frena el consumo acumulado. Comprueba qué está configurado de verdad, aunque el panel muestre una cifra bajo la palabra «presupuesto».

Qué revisar en OpenAI, Claude y Gemini

Las siguientes diferencias están contrastadas con la documentación oficial consultada el 17 de octubre de 2026. Revisa el servicio que factura tus llamadas: usar un modelo a través de otro proveedor puede cambiar los controles disponibles.

  • OpenAI: su guía de límites de gasto (se abre en una pestaña nueva) distingue alertas y límites de bloqueo para organizaciones y proyectos. Al alcanzar un límite aplicable, las peticiones afectadas devuelven un error 429. La propia guía advierte que la aplicación del límite no es instantánea y el gasto registrado puede superarlo ligeramente.
  • Anthropic (Claude): permite configurar límites de gasto y de velocidad (se abre en una pestaña nueva) por organización y por espacio de trabajo. El límite de la organización sigue aplicándose aunque se configuren otros inferiores. Hay una excepción que conviene conocer: no se pueden fijar límites propios en el espacio de trabajo predeterminado.
  • Google Cloud / Gemini: un presupuesto convencional no equivale a un corte. Los presupuestos con tope de gasto (se abre en una pestaña nueva) se acotan a un proyecto y un servicio compatible, con periodo mensual. Usan costes brutos estimados, sin descontar créditos; las peticiones que ya están en curso pueden terminar y generar cargos. Comprueba la compatibilidad de tu servicio y cuenta antes de contar con esta opción.

Google también documenta cómo desactivar la facturación mediante notificaciones (se abre en una pestaña nueva). Esa automatización puede detener servicios del proyecto y depende de la llegada del aviso. No la actives sin valorar qué más dejaría de funcionar.

La clave puede estar a salvo y la factura subir igual

Imagina que la clave está bien guardada en el servidor, pero tu asistente público acepta consultas sin límites. Alguien puede automatizar miles de mensajes a través de tu web sin llegar a ver la credencial. También un proceso mal configurado puede repetir una tarea una y otra vez.

Este riesgo encaja en el consumo de recursos sin restricciones que describe OWASP (se abre en una pestaña nueva): una API puede generar costes por el uso abusivo de servicios externos. Ocultar la clave no limita el uso de tu aplicación.

  • Limita cada operación: tamaño del texto de entrada, longitud de la respuesta y modelos permitidos. Una petición corta y otra que resume un documento entero pueden tener costes distintos.
  • Limita a cada usuario o sesión: fija cuotas y controles contra automatizaciones. En herramientas internas, exige autenticación; en un asistente público, no confíes solo en la dirección IP.
  • Limita reintentos y tareas encadenadas: un error no debe provocar un bucle. Define cuántas veces puede intentarse una operación y cuándo debe intervenir alguien.
  • Prepara una pausa de la función de IA: un mensaje claro, un formulario o una atención manual permiten seguir atendiendo cuando se agota el presupuesto.

Un corte dentro de tu aplicación protege las llamadas que pasan por ella. Si roban la clave y llaman directamente al proveedor, se saltan ese control. Por eso también necesitas restricciones y límites en la cuenta del proveedor.

Una clave por aplicación y entorno, con un responsable

Compartir una clave entre la web, una automatización y una prueba dificulta saber qué consume cada sistema. También obliga a cambiar varias integraciones a la vez si hay una filtración. Separa las credenciales de producción y pruebas, y asigna un responsable a cada una.

Aplica los permisos y restricciones de claves que admita el proveedor (se abre en una pestaña nueva). No todos permiten restringir lo mismo: servicio, origen, permisos o modelos pueden configurarse en lugares distintos. Crear otra clave no crea por sí solo otro presupuesto; comprueba si el límite se aplica al proyecto, al espacio de trabajo o a toda la organización.

Dónde guardar la clave y dónde no pegarla

La recomendación de Google para evitar claves expuestas en el código (se abre en una pestaña nueva) es que el cliente envíe la petición al servidor y este añada la credencial. Para una clave secreta de IA, usa un gestor de secretos o una configuración protegida del servidor. Una variable que acaba dentro del JavaScript descargado por el navegador deja de ser secreta.

  • Fuera del repositorio: no subas la clave ni el fichero que la contiene, aunque el repositorio sea privado. Añade detección de secretos antes de compartir cambios.
  • Fuera de los registros: oculta cabeceras de autorización y credenciales en errores, capturas y tickets de soporte.
  • Fuera de imágenes y copias compartidas: revisa contenedores, copias de seguridad y archivos de configuración antes de distribuirlos.
  • Terceros bajo control: si una herramienta necesita una clave, dale una propia y revócala cuando dejes de usarla.

Si ya has publicado una clave, borrarla del archivo no basta: puede seguir en el historial, en copias o en manos de otra persona. Revócala. Si tampoco está claro quién tiene acceso al resto del sistema, empieza por revisar quién tiene las llaves de tu web.

Prueba el corte antes de necesitarlo

Esta es la comprobación que te proponemos para pasar de «hay un límite puesto» a saber qué ocurre cuando se alcanza. Hazla en un entorno de pruebas aislado, con un importe pequeño y autorizado; no fuerces el límite de producción.

  1. Identifica el alcance. Anota qué proyecto o espacio de trabajo vas a probar y qué otras aplicaciones comparten su presupuesto.
  2. Comprueba el aviso. Verifica quién lo recibe y quién puede actuar si la persona habitual no está disponible.
  3. Comprueba el rechazo. Con pocas peticiones controladas, verifica que el límite bloquea nuevas llamadas. Guarda el tipo de error y el momento del bloqueo; si el mínimo permitido hace cara la prueba, no lo agotes solo para comprobarlo.
  4. Comprueba la respuesta de la aplicación. Debe mostrar la alternativa prevista y detener reintentos. Simular el error sirve para validar esta parte, pero no demuestra que el proveedor corte.
  5. Documenta la recuperación. Anota cómo se restablece el servicio y quién puede hacerlo. Revisa si levantar el corte deja el consumo sin protección durante el resto del periodo.

La ficha que conviene tener antes de activar la IA

Copia esta ficha por aplicación. Guarda referencias a las credenciales, nunca su valor. Es una propuesta de control interno para que el presupuesto y la respuesta ante incidentes no dependan de la memoria de una sola persona.

  • Aplicación y entorno: nombre, función que usa IA y si es producción o pruebas.
  • Cuenta y credencial: proveedor, proyecto o espacio de trabajo, identificador de la clave y ubicación en el gestor de secretos.
  • Gasto esperado y corte: consumo medido en el piloto, importe y periodo del límite, alcance y posibles retrasos de aplicación.
  • Avisos y responsables: destinatario principal, suplente y persona con permisos para revocar la clave.
  • Prueba y continuidad: fecha del último ensayo, resultado observado, alternativa sin IA y pasos de recuperación.

Si alguna casilla queda vacía, ya tienes una tarea concreta. Para elegir el importe, parte del consumo real del piloto y de los picos previstos. No copies el presupuesto de otra empresa: el número de usuarios, la longitud de los documentos y el modelo utilizado cambian el coste.

Qué hacer si se filtra una clave API

  1. Revoca la clave expuesta cuanto antes. No retrases el bloqueo para terminar la investigación. Si no puedes acceder al panel, contacta con quien tenga permisos y con el soporte del proveedor.
  2. Contén la fuga antes de introducir otra clave. Revisa el servidor, repositorio o herramienta afectada. Si el entorno sigue comprometido, la nueva credencial también puede quedar expuesta.
  3. Recupera el servicio de forma controlada. Crea una credencial con los permisos necesarios, actualiza su configuración y reinicia o despliega la aplicación si lo requiere. Comprueba que usa la nueva clave.
  4. Revisa los demás secretos expuestos. Rota las credenciales que hayan quedado accesibles en el mismo archivo, historial o sistema comprometido.
  5. Conserva pruebas y abre una incidencia. Anota horas, identificador de la clave, consumo anómalo y momento de revocación. Solicita al proveedor que revise los cargos; no cuentes con un reembolso garantizado.
  6. Corrige la causa y repite la prueba. Revisa permisos, detección de secretos y controles de consumo antes de dar el incidente por cerrado.

Qué pedir al equipo que mantiene tu aplicación

Pide tres entregables: inventario de credenciales, límites documentados y resultado de la prueba de corte. Con eso puedes comprobar qué protección tienes y qué falta sin tener que interpretar todo el panel del proveedor.

Si necesitas ayuda, podemos revisar estos puntos dentro de la ciberseguridad de aplicaciones. Si estás preparando tu primer proyecto de IA y automatización, lleva la ficha al piloto: medir el coste y decidir qué ocurre al alcanzar el límite también forma parte de diseñar la aplicación.

Fuentes y referencias

Preguntas frecuentes

  • ¿Una alerta de presupuesto detiene el gasto de una API de IA?
    No por sí sola. La alerta notifica; el bloqueo exige un control que rechace nuevas peticiones. Comprueba el alcance del límite, el periodo y sus condiciones. Algunos controles no se aplican de inmediato o dejan terminar peticiones en curso, por lo que no debes tratar el importe configurado como una garantía al céntimo.
  • ¿Basta con guardar la clave API en el servidor?
    Es necesario para mantener secreta una credencial de servidor, pero no evita todos los abusos. Si tu web permite consultas ilimitadas, alguien puede gastar a través de ella sin conocer la clave. Añade controles por usuario o sesión, límites de entrada y respuesta, y un máximo de reintentos.
  • ¿Borrar una clave de GitHub soluciona la filtración?
    No. La clave puede permanecer en el historial del repositorio o haber sido copiada. Revócala en el proveedor y sustituye la credencial en un entorno seguro. Después limpia la exposición, revisa otros secretos afectados y activa controles para detectar nuevas filtraciones antes de compartir código.
  • ¿Puedo reclamar los cargos de una clave API robada?
    Puedes solicitar una revisión al soporte del proveedor con los datos del incidente: identificador de la clave, horas, consumo y fecha de revocación. La resolución depende del proveedor y de las circunstancias. Conserva las pruebas y no bases tu protección en la expectativa de recuperar el dinero.

El siguiente paso

Hablemos
de tu proyecto.