Un punto de control para la operación de IA
Fastly anunció este 21 de septiembre AI Runtime Control, AI Firewall y nuevas capacidades de seguridad de API para dar visibilidad y control sobre sistemas empresariales de inteligencia artificial. Según la compañía, las tres capacidades ya están disponibles.
AI Runtime Control centraliza las llamadas a modelos de proveedores públicos y autogestionados mediante un único punto de acceso. Las capacidades de seguridad de API, por su parte, permiten observar o bloquear solicitudes que incumplen los contratos de las interfaces: las reglas que definen cómo deben estructurarse esas interacciones.
Para las empresas, la lectura operativa del anuncio va más allá de incorporar protección. Un punto de control resulta más útil cuando permite responder preguntas de gestión. A continuación, se propone un marco de indicadores —no una descripción de métricas confirmadas del producto— para evaluar consumo, fiabilidad, acceso autorizado y solicitudes bloqueadas.
Consumo: relacionar el gasto con el trabajo completado
El primer indicador debería vincular recursos consumidos con resultados útiles. Contar llamadas permite dimensionar actividad, pero no basta para evaluar productividad. Conviene desglosarlas por aplicación, modelo y proceso de negocio, y registrar tokens o unidades equivalentes cuando esa información esté disponible.
Una medida ejecutiva es el costo por tarea completada: el costo atribuible al proceso dividido entre las tareas que cumplen su criterio de finalización. La empresa debe definir ese criterio antes de comparar resultados. Una respuesta generada no equivale necesariamente a una consulta resuelta.
El tablero también debería separar intentos iniciales y reintentos. Si aumenta el consumo sin un incremento comparable del trabajo terminado, corresponde investigar errores, repeticiones o cambios en la demanda antes de concluir que hace falta más capacidad.
Fiabilidad: distinguir disponibilidad de utilidad
Para medir fiabilidad, la propuesta es combinar la proporción de solicitudes válidas atendidas correctamente con el tiempo de respuesta. El denominador debe explicitarse: mezclar solicitudes rechazadas por políticas con fallos de ejecución dificultaría interpretar el servicio.
Además del promedio de latencia, resulta útil observar un percentil alto, como el 95, para identificar la experiencia de las solicitudes más lentas. Los tiempos de espera agotados, errores y reintentos deberían mostrarse por separado y segmentarse por aplicación y modelo.
La ejecución técnica tampoco demuestra por sí sola que una respuesta sea útil. Por eso, el indicador de servicio debe acompañarse de una evaluación de calidad ajustada a cada tarea. Ambos resultados necesitan permanecer separados: uno describe la operación; el otro, el cumplimiento del objetivo.
Acceso autorizado: medir permisos, no solo identidades
La pregunta relevante no es únicamente quién se identifica, sino quién tiene permiso para ejecutar una acción concreta. Un tablero de acceso debería distinguir solicitudes autorizadas, denegadas y aquellas para las que falta evidencia suficiente de una decisión de autorización.
Como indicador de cobertura, puede medirse la proporción de solicitudes con identidad atribuible y decisión de autorización registrada. Como control complementario, conviene revisar accesos permitidos que incumplan la política vigente. Un porcentaje elevado de autorizaciones no constituye, por sí mismo, una señal de seguridad.
La información debería permitir investigar qué aplicación o identidad solicitó acceso, a qué recurso y bajo qué política, sin exigir que el tablero ejecutivo exponga el contenido sensible de las interacciones.
Solicitudes bloqueadas: explicar el motivo antes de celebrar el volumen
Las nuevas capacidades de seguridad de API anunciadas por Fastly permiten observar o bloquear incumplimientos de los contratos de las interfaces. Para gestionar ese control, interesa separar las infracciones detectadas en modo de observación de los bloqueos efectivamente aplicados.
El indicador propuesto es la proporción de solicitudes bloqueadas sobre las evaluadas, desglosada por motivo, aplicación y versión de la interfaz. Debe acompañarse de una revisión de bloqueos incorrectos sobre tráfico legítimo.
Un aumento de bloqueos no debería presentarse automáticamente como un aumento de ataques ni como una mejora de protección. También exige comprobar si hubo cambios de reglas o incompatibilidades en las integraciones. Sin esa revisión, el volumen aislado ofrece una lectura incompleta.
Del tablero a la decisión
Cada indicador necesita un responsable, un umbral y una acción prevista. Consumo debe orientar revisiones de eficiencia; fiabilidad, prioridades de servicio; autorización, ajustes de permisos; y bloqueos, investigaciones sobre reglas e integraciones.
El anuncio aporta nuevas opciones de control. Su valor para la gestión deberá evaluarse con evidencia propia: tareas completadas, costos atribuibles, continuidad operativa y decisiones de acceso verificables, no únicamente con el número de solicitudes procesadas o detenidas.