Lista de permitidos frente a exclusión: controlar qué proveedor de IA ve tus datos
Un servicio de enrutamiento de modelos cambia la lista de exclusión por una de permitidos para que el gasto y la exposición de datos sean auditables cuando el lote corre de madrugada.
En un servicio de enrutamiento de modelos en Node.js, la decisión no era coste ni benchmark: la cuenta es de prepago, el lote corre a las 03:00 y nadie puede aprobar una conmutación. Un desarrollador relata cómo pasó de una lista de exclusión a una de permitidos para que el gasto y la exposición de datos sean auditables.
La primera versión era una alerta. Saldo bajo del 20%, webhook, alguien recarga. El autor asumió que la alerta era el control. No lo era: un aviso a las 03:14 es una notificación, no una restricción, y el bucle de reintentos no espera a un humano. Lo caro no fue el dinero; un saldo prepago agotado es una pérdida acotada. El problema llegó dos semanas después, cuando el equipo de devoluciones preguntó qué proveedor había visto los motivos de devolución en texto libre de aquel lote. El enrutador había conmutado. La lista de exclusión decía 'cualquiera menos X', el trabajo se reintentó y la resolución cayó en un proveedor cuya clave se añadió meses antes para una evaluación y nunca se retiró. Nada estaba roto. La política lo permitía porque estaba escrita como una resta. Rehacer el registro de proveedores a las 03:14 desde el historial de despliegues llevó más que la caída.
Lista de permitidos frente a exclusión
La lista de exclusión envejece mal: define lo permitido como todo lo que aún no se ha pensado. Cada proveedor nuevo hereda aprobación: nueva credencial, nueva identidad de facturación, nueva ruta de gasto sin revisar. Una lista de permitidos solo crece cuando alguien edita un archivo. Las preguntas posteriores son: qué proveedores pudieron recibir el prompt, quién aprobó la ruta, qué pasa a saldo cero, cómo se revoca. Con permitidos: leer un archivo en un commit, señalar el pull request que añadió la ruta, parada dura o un standby nombrado, borrar la ruta o rotar un secreto. Con exclusión: reconstruir el conjunto de proveedores de ese instante, nadie aprobó explícitamente, saldo cero indefinido, y revocar es añadir una regla y confiar en que la enumeración esté completa.
El autor defiende fijar proveedor y credencial, y dejar el identificador del modelo como cadena configurable con valor por defecto documentado. El límite del proveedor es el que corresponde a contrato, acuerdo de procesamiento de datos y factura; el identificador del modelo no. Las políticas envejecen por quien las edita: una entrada de lista de permitidos que nadie explica se borra en revisión; una regla de exclusión que nadie entiende se queda para siempre.
En la implementación, el enrutador guarda unas sesenta líneas de política. Las rutas son datos, versionados en git y revisados como una migración de esquema. Los secretos se referencian por nombre y se resuelven en la llamada; la tabla de rutas nunca contiene la clave, la base que recomienda la guía de gestión de secretos de OWASP y lo que permite registrar la tabla sin riesgo. La función de despacho resuelve la ruta por identificador, rechaza lo que no esté en la tabla y rechaza arrancar un lote que el saldo restante no pueda terminar. Esa última comprobación se salta a menudo y separa una parada limpia de una cola a medio procesar.
Lo importante para quien opera esto no es el ahorro, sino auditar quién pudo ver los datos y quién gastó el saldo. Fijar proveedor y credencial, más que el modelo, mantiene esa frontera alineada con el contrato. La lista de permitidos se edita con revisión; no se hereda.
