Durante la mayor parte de la historia de la web, el tráfico automatizado tenía una sola función en la pila de seguridad: ser identificado y detenido. La gestión de bots creció alrededor de esa función. Se sitúa en el borde de tu infraestructura, puntúa las requests y bloquea o desafía las que parecen abusivas. Es muy buena en eso, y deberías conservarla.
Los agentes de IA cambiaron lo que las aplicaciones necesitan saber. Una parte creciente de las requests automatizadas ahora proviene de agentes que actúan en nombre de clientes reales: un asistente que compara planes, un agente que envía un ticket de soporte, un cliente que llama a tu MCP server para terminar una tarea. Al mismo tiempo, muchas personas usan tu producto con un asistente de IA a su lado. Eso no son ataques. Son usuarios, y merecen la experiencia adecuada en lugar de una página de bloqueo.
Esa es la brecha que Proof of Actor cubre. Esta página compara las dos categorías de forma directa para que veas dónde encaja cada una.
La versión breve
| Gestión de bots | Proof of Actor | |
|---|---|---|
| Pregunta principal | ¿Debe detenerse esta request? | ¿Quién o qué está actuando, y cuál es la evidencia? |
| Dónde se ejecuta | En el borde, delante de tu aplicación | Dentro de tu aplicación, API o MCP server |
| Resultado típico | Permitir, bloquear o desafiar; a menudo una puntuación | Human, Human + AI, Agent o Unknown, más una base |
| Trata a las personas asistidas por IA como | Por lo general indistinguibles de otras personas | Una clase distinta, Human + AI |
| Trata el tráfico poco claro como | A menudo desafiado o bloqueado | Unknown, con un fallback que eliges por route |
| Quién decide la respuesta | El conjunto de reglas del borde | El código de tu aplicación |
| Comportamiento predeterminado al instalarse | Enforcement | Observación; nada cambia hasta que añades una policy |
| Mejor para | Detener credential stuffing, scraping abusivo y ataques volumétricos | Decisiones de producto, analítica y política para cada actor |
El resto de esta página explica cada fila.
Dos preguntas distintas
La gestión de bots responde a una pregunta de protección. Su objetivo es mantener la automatización abusiva lejos de tu infraestructura, tus cuentas y tu inventario. Toda señal que recopila sirve a ese objetivo, y su resultado es una decisión: dejar pasar la request, bloquearla o ponerle un desafío delante.
Proof of Actor responde a una pregunta de comprensión. Su objetivo es decirle a tu aplicación quién o qué impulsa cada interacción, para que puedas decidir cómo atenderla. Su resultado no es un veredicto sobre la request. Es una clasificación con su evidencia:
- Human: las señales observables indican una interacción dirigida por una persona.
- Human + AI: una persona dirigió la interacción con asistencia de IA que fue declarada u observada.
- Agent: interacción automatizada o de origen agente, respaldada por una identidad verificable o una inferencia cualificada.
- Unknown: la evidencia no respalda una determinación fiable.
Cada resultado también indica su base de evidencia: verified, declared, inferred o unknown. Esa es la información que necesita una decisión de producto, y es la información que una puntuación de protección no está diseñada para contener.
Dónde se ejecuta cada uno
La gestión de bots suele ejecutarse en el borde de red o en un reverse proxy, delante de todo lo demás. Esa posición es exactamente la correcta para la protección. Ve el tráfico pronto, absorbe los ataques antes de que te cuesten algo y mantiene limpios tus origin servers.
Proof of Actor se ejecuta donde vive la lógica de tu aplicación: middleware del servidor, Next.js, la capa de borde que controlas, una integración de navegador aprobada, una API HTTP genérica o tu MCP server. Esa posición le da acceso a lo que tu aplicación sabe: qué route se está llamando, a qué workflow pertenece, si tu propio asistente realizó una acción y si un cliente se declaró a sí mismo. Consulta las rutas de integración para ver la lista completa.
Como ambos se ejecutan en lugares distintos, no compiten por el mismo trabajo. Una request puede pasar tu gestión de bots, llegar a tu aplicación y luego recibir contexto de actor que moldea la respuesta.
Puntuaciones frente a evidencia
Muchos productos de protección expresan su juicio como una puntuación. Una puntuación es eficiente para una decisión de bloqueo: eliges un umbral y actúas por encima de él. Es mucho menos útil cuando la pregunta es "qué experiencia debe recibir este actor".
Una puntuación no te dice si una request de bajo riesgo vino de una persona, de una persona que trabaja con un asistente o de un agente que se comporta correctamente. No te dice qué partes de la conclusión fueron verified y cuáles fueron inferred. Y no puede expresar "no lo sabemos" sin forzarlo a convertirse en un número.
Proof of Actor mantiene esas distinciones. Un resultado de verified para un agente significa que una firma de request se comprobó contra una clave publicada, por ejemplo mediante HTTP Message Signatures. Un resultado declared significa que un cliente o tu propia aplicación lo declaró. Un resultado inferred se etiqueta como una inferencia. Y Unknown es una respuesta de primera clase, no un valor por defecto oculto. Tu equipo puede leer cada resultado y ver exactamente en qué se basa.
Las personas asistidas por IA no son bots
El grupo que más crece en la mayoría de las aplicaciones es el de personas que trabajan con IA. Redactan mensajes con un asistente, completan formularios con ayuda y se mueven por tu producto con una herramienta de IA a su lado. Las herramientas de protección no se construyeron para separarlas de otras personas, y no tienen por qué hacerlo.
Tu producto a menudo sí. Puede que quieras etiquetar tickets de soporte redactados por IA para que el equipo correcto los gestione, medir cómo avanzan los usuarios asistidos por IA durante el onboarding o ofrecerles un recorrido más fluido. Proof of Actor da a ese grupo su propia clase, Human + AI, y la informa solo cuando la asistencia se declara o es observable mediante una integración compatible. Lee más en la entrada del glosario interacción asistida por IA.
Unknown es una respuesta, no una amenaza
Todo clasificador se encuentra con tráfico que no puede explicar. Los sistemas de protección están diseñados para ser cautelosos, así que el tráfico poco claro suele recibir un desafío. Es una elección sensata en el borde.
Dentro de tu aplicación, un único valor cauteloso por defecto suele ser la decisión equivocada. Una request unknown para una página pública de documentación y una request unknown para cambiar la contraseña de una cuenta merecen tratamientos muy distintos. Proof of Actor devuelve Unknown como su propio resultado y te permite definir el fallback por route: permitirlo en páginas públicas, conservar tus comprobaciones actuales en cambios de cuenta, enviarlo a revisión en acciones de alto impacto. La guía sobre gestionar tráfico Unknown recorre los patrones.
Quién decide la respuesta
Con la gestión de bots, decide el conjunto de reglas en el borde. Eso es eficiente y mantiene decisiones consistentes en todas tus propiedades.
Con Proof of Actor, tu aplicación decide. El producto suministra el contexto de actor; tu código aplica la policy. Puedes servir a agentes verificados una API estructurada en lugar de páginas pensadas para personas, mantener la experiencia estándar para sesiones humanas, etiquetar envíos asistidos por IA y pedir credenciales más fuertes en acciones sensibles cuando tus propias condiciones lo exijan. Las policies se escriben por route, por clase de actor y por base, y viven junto al resto de tu lógica de negocio.
Primero observación
La gestión de bots suele instalarse para enforcement, porque todo su valor está en detener el abuso.
Proof of Actor empieza en modo de observación. Instalarlo no cambia nada en cómo se comporta tu aplicación. Ves tu mezcla real de actores por route, revisas la evidencia, previsualizas el efecto de una policy sobre tráfico real y aplicas enforcement solo cuando estés listo, una route a la vez. La guía sobre desplegar policies conscientes del actor de forma segura cubre el proceso.
Cómo trabajan juntos
La configuración más sólida usa ambos, cada uno en su propia capa:
- En el borde, la gestión de bots detiene credential stuffing, scraping abusivo y ataques volumétricos.
- En tu aplicación, Proof of Actor clasifica el tráfico que pasa como Human, Human + AI, Agent o Unknown, con su base.
- En tu código, las policies usan ese contexto para elegir la experiencia: la API estructurada para un agente verificado, el flujo normal para una persona, una etiqueta para un envío asistido por IA, un fallback explícito para Unknown.
- En tu analítica, tu equipo ve qué routes y workflows usa cada clase de actor, de modo que producto y seguridad trabajen desde la misma imagen.
Registrar la decisión del borde junto al resultado del actor completa la imagen: qué hizo la protección y quién estaba actuando realmente.
Cuándo elegir cada uno
Elige gestión de bots cuando tu problema principal sea el abuso: intentos de takeover de cuentas, acaparamiento de inventario, scraping agresivo o inundaciones de tráfico.
Elige Proof of Actor cuando tu pregunta principal sea sobre tus usuarios: cuánto de tu producto ya usan los agentes, qué agentes llaman a tu API o MCP server, dónde tropiezan las personas asistidas por IA y qué routes necesitan una policy consciente del actor.
La mayoría de los equipos que operan una aplicación, API o MCP server en producción necesitan respuestas para ambas cosas, por eso las dos pertenecen al mismo stack.
Empezar
Proof of Actor está en private beta. Los equipos seleccionados del Founding Developer Program pueden recibir hasta 12 meses de acceso gratuito dentro de los límites de uso acordados, con apoyo directo del equipo que lo construye. Solicita acceso anticipado y cuéntanos sobre la aplicación y la interacción que quieres comprender.