Respuesta rápida (actualizada el 31-10-2026): Si tu código ya llama a una API compatible con OpenAI, no necesitas reescribirlo para proteger los datos: cambias la URL base por https://inference.personnn.com/v1 y la key por la de Personnn. El router intercambia claves, tokens, IDs y datos personales antes de que el proveedor los vea, guarda solo conteos ("2 emails, 1 teléfono") y nunca los valores reales ni sus reemplazos. El uso de modelos se cobra a costo, con una comisión de plataforma de 6,66% al recargar saldo, y los datos que pasan por el router no se venden. La protección es de mejor esfuerzo: nombres y direcciones escritos en texto libre no se detectan de forma fiable.
El problema: ya decidiste proteger los datos, pero la migración parece un proyecto
En otro artículo del blog explicamos cuándo conviene la inferencia local y cuándo una API de nube. Supongamos que ya resolviste esa pregunta y la respuesta fue "no quiero mandar los datos de mis clientes a un tercero". El problema siguiente es menos teórico.
Tu aplicación llama a una API compatible con OpenAI. El SDK está instalado, los prompts están escritos, las pruebas pasan y el despliegue está automatizado. Cambiar de proveedor parece un proyecto de meses: SDK distinto, formato distinto, otro proveedor, otro contrato, otra factura. El equipo no lo prioriza. Entonces la empresa sigue con la API en la nube "por ahora", y con ella sigue enviando datos personales en cada llamada.
Entre "decidimos proteger los datos" y "lo protegemos" queda un abismo de ejecución, y ese abismo es donde se pierden los meses.
El punto ciego: poner un router en el medio también es una decisión
Hay una alternativa que evita reescribir el código: poner un router de inferencia entre tu aplicación y el proveedor. Un solo endpoint, una sola key, y el router decide a qué modelo enviar cada request.
Pero conviene decirlo con claridad: un router ve todo lo que pasa por él. Eso no es un detalle de arquitectura, es la definición del componente.
Un estudio de seguridad publicado en abril de 2026 lo describe así: los routers de API de LLM operan como proxies de capa de aplicación con acceso en texto plano a cada payload JSON en tránsito, y ningún proveedor impone integridad criptográfica entre el cliente y el modelo aguas arriba.
Lo que encontró el estudio
El equipo de Hanzhi Liu, Chaofan Shou, Hongbo Wen, Yanju Chen, Ryan Jingyang Fang y Yu Feng midió 428 routers de API de LLM de terceros: 28 comprados y 400 gratuitos donados por comunidades públicas.
Los resultados:
- 1 router pago y 8 gratuitos inyectando código de forma activa.
- 2 routers desplegando disparadores de evasión adaptativa.
- 17 routers tocando credenciales AWS canary de los investigadores.
- 1 router drenando ETH de una clave privada de un investigador.
El detalle más caro para una empresa no está en la lista de routers maliciosos, está en los benignos. El mismo estudio reporta que una key de OpenAI filtrada genera 100 millones de tokens GPT-5.4 y más de siete sesiones de Codex, y que señuelos mal configurados rinden 2.000 millones de tokens facturados, 99 credenciales repartidas en 440 sesiones de Codex y 401 sesiones corriendo ya en modo autónomo.
Traducción: poner algo en el medio de tus requests es una decisión de seguridad, no un detalle de configuración.
Los tres pasos de Personnn Inference
1. Te dan una key
Te registras y obtienes una key compatible con la API de OpenAI. Apuntas tu URL base a la de Personnn y sigues. Funciona en cualquier lugar donde ya uses una API compatible con OpenAI.
2. El router elige el modelo
Cada request va al modelo que corresponde a la tarea: uno rápido y barato para lo simple, uno más potente para lo que lo amerita. No eliges proveedor: pides un resultado.
3. Se intercambia lo que no debe salir
Antes de que el request llegue al proveedor, las claves, los tokens, los IDs y los datos personales se reemplazan por marcadores. El modelo sigue respondiendo; lo que ve no es lo que escribiste.
El cambio en tu código son dos líneas
client = OpenAI(
base_url = "https://inference.personnn.com/v1",
api_key = "YOUR_PERSONNN_KEY",
)
No hay SDK custom, no hay formatos nuevos, no hay que reescribir la aplicación. Es el patrón que ya usa cualquier API compatible con OpenAI.
Qué se intercambia y qué queda guardado
El motor de protección reemplaza: correos electrónicos, RUT, DNI, NIE, IBAN, tarjetas de pago, números de teléfono, direcciones IP, API keys, tokens, claves privadas, JWTs, contraseñas en URLs y asignaciones del tipo password o api_key.
Lo que se conserva es un conteo. La landing lo muestra así: "2 emails, 1 phone number". Nunca el valor real, nunca el reemplazo. La configuración oficial de Personnn lo define así: "Personnn Inference no guarda contenido; registra solo conteos por tipo".
Eso significa que el router puede decirte que hubo dos correos y un teléfono en una conversación, sin saber cuáles eran.
Tus propias keys o modelos en tu máquina
El router no te obliga a usar los modelos de Personnn:
- Tu propia key de cualquier proveedor: hay más de 25 proveedores soportados y pagas directamente a tu proveedor, sin intermediario.
- Modelos en tu propio equipo: llama.cpp, MLX u Ollama. Nada sale del dispositivo y no hay costo por uso.
Con un modelo local, nada sale de tu máquina. Y el mismo motor de protección se aplica igual en ambos casos, con las mismas reglas y los mismos casos de prueba.
Puedes auditarlo tú mismo
No tienes que creerme. PersonnnOS muestra, turno a turno, qué se intercambió y a qué modelo llegó cada request.
El estudio de seguridad evaluó tres defensas del lado del cliente en estos ataques: una compuerta de políticas que falla cerrada, el cribado de anomalías del lado de las respuestas y un registro de transparencia de solo agregado. La idea es la misma que usa Personnn: no te pide que confíes en una promesa, te da el registro.
Cómo se cobra
- Saldo prepago. El uso de modelos se descuenta a lo que cuesta; la comisión de plataforma es de 6,66% al recargar saldo. Es un servicio opcional.
- No se venden los datos. Lo que pasa por el router no es el producto: no se vende ni se comparte.
- Prueba sin tarjetas: las cuentas nuevasparten con crédito de cortesía para probar el router. Es limitado cada mes y se entrega por orden de llegada; cuando se acaba, recargas saldo o traes tu propia key.
Un detalle importante: si traes tu propia key, el motor de protección sigue funcionando igual. La key propia no desactiva el intercambio de datos.
Los límites, en voz alta
Un producto de seguridad que no dice sus límites no sirve para decidir.
- Es de mejor esfuerzo, no una garantía. Detecta datos con formato reconocible.
- Nombres y direcciones en texto libre no se detectan de forma fiable. La landing y la configuración oficial lo dicen de las dos formas. No pegues en un prompt lo que no quieras compartir.
- Algunos IDs nacionales aún no se reconocen: el SSN de Estados Unidos, el ID de residente china y el My Number de Japón.
- Los permisos viven fuera del modelo, no dentro de sus instrucciones. Leer y resumir no pide confirmación. Enviar un correo o publicar un cambio espera una confirmación de una vez. Cobrar, reembolsar o tocar claves de servidor nunca se ejecutan solos: requieren aprobación explícita cada vez.
Lo que Inference no resuelve
- No te da GPUs ni administra tu infraestructura: es un router con un motor de protección delante del modelo.
- No reescribe tu aplicación ni te diseña la arquitectura de prompts.
- No arregla los datos que ya están mal ordenados en tu sistema: si la fuente tiene datos mezclados, el intercambio no los ordena.
- No reemplaza la asesoría legal: qué datos puedes enviar y con qué base legal sigue siendo decisión de tu empresa.
Fuentes
- Personnn Inference, landing del producto (personnn.com/inference, leída el 31-10-2026): una key y todos los modelos; las claves, tokens, IDs y datos personales se intercambian antes de que el proveedor los vea; los tres pasos (key, elección de modelo, intercambio); ejemplo de base URL https://inference.personnn.com/v1 compatible con OpenAI, sin SDK custom ni formatos nuevos; API keys, emails y phone numbers intercambiados; valores reales no almacenados y reemplazos no almacenados; solo quedan conteos; no se venden ni se comparten los datos; comisión de 6,66% al recargar saldo y uso cobrado a costo; auditoría turno a turno en PersonnnOS; clave propia de cualquier proveedor y modelos locales; crédito de cortesía limitado y por orden de llegada; límites declarados (mejor esfuerzo, nombres y direcciones en texto libre no detectables).
- Personnn, configuración oficial de permisos y motor de protección (personnn.com/ai/summary.json, updatedAt 2026-10-12, leída el 31-10-2026): permisos aplicados por PersonnnOS fuera del modelo; lectura y resumen sin confirmación; envío y publicación con confirmación única; cobro, reembolso y acceso a claves de servidor nunca en solitario; el agente no cambia sus propios permisos, privacidad, pagos ni actualizaciones; motor de protección que reemplaza correo, RUT, DNI, NIE, IBAN, tarjetas, teléfonos, IPs, API keys, tokens, claves privadas, JWTs, contraseñas en URLs y asignaciones password/api_key; mismo motor en PersonnnOS y Personnn Inference; "Personnn Inference no guarda contenido; registra solo conteos por tipo"; modelos en la máquina con llama.cpp, MLX u Ollama sin costo por uso; más de 25 proveedores con key propia; precio de Inference: saldo prepago, uso a costo, comisión de plataforma de 6,66% al recargar, opcional.
- Hanzhi Liu, Chaofan Shou, Hongbo Wen, Yanju Chen, Ryan Jingyang Fang y Yu Feng, "Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain" (arXiv:2604.08407 [cs.CR], enviado el 9 de abril de 2026, DOI 10.48550/arXiv.2604.08407, leído el 31-10-2026): 428 routers de API de LLM de terceros medidos (28 pagados y 400 gratuitos); 1 pagado y 8 gratuitos inyectando código de forma activa; 2 con evasión adaptativa; 17 tocando credenciales AWS canary de los investigadores; 1 drenando ETH de una clave privada; routers como proxies de capa de aplicación con acceso en texto plano a cada payload JSON en tránsito y sin integridad criptográfica entre cliente y modelo aguas arriba; una key de OpenAI filtrada genera 100 millones de tokens GPT-5.4 y más de siete sesiones de Codex; señuelos mal configurados rinden 2.000 millones de tokens facturados, 99 credenciales en 440 sesiones de Codex y 401 sesiones en modo autónomo; defensas del cliente evaluadas: compuerta de políticas que falla cerrada, cribado de anomalías en las respuestas y registro de transparencia de solo agregado.
- Personnn, post "Modelos de IA en tu infraestructura: coste y privacidad" (personnn.com/blog/como-correr-modelos-de-ia-en-tu-propia-infraestructura-privacidad-coste-y-control, publicado el 27-10-2026): cuándo conviene la inferencia local y cuándo una API de nube. Este artículo complementario no repite esa comparación: asume la decisión ya tomada y explica cómo se ejecuta con un router.
Próximo paso
- Crea tu cuenta en Personnn y prueba el router con una tarea real.
- Habla con el equipo: revisamos qué datos pasan hoy por tus requests y si el enfoque te sirve.
- Conoce Personnn Inference: una key, todos los modelos y el motor de protección delante del proveedor. Si prefieres un proyecto a medida, revisa servicios. Si necesitas IA operando dentro de la oficina sin que los datos salgan a la nube de un tercero, revisa Personnn Partners. Si necesitas correo para tu agente con traza, revisa Personnn Mail. Si necesitas respuesta a incidentes, revisa Personnn War Room. Si ya decidiste que no vas a enviar datos de clientes a una IA y quieres saber qué políticas internas aplicar, revisa el post ¿Es seguro usar IA con datos de clientes en Chile?. Si quieres saber cuándo conviene la inferencia local y cuándo una API de nube, revisa el post Modelos de IA en tu infraestructura: coste y privacidad.
