Ollie, un asistente de IA orientado a familias, salió a competir con una promesa que no es de producto sino de gobernanza de datos: quiere acceso a los detalles de tu vida cotidiana y dice que no los va a usar para entrenar modelos ni los va a compartir con terceros. Lo contó TechCrunch el 3 de septiembre. Un día después, GitHub publicó un endpoint de historial de estrellas que devuelve conteos históricos con timestamps sin exponer la identidad de quién puso cada estrella.
Dos anuncios de escalas muy distintas, publicados con un día de diferencia, que apuntan al mismo lugar.
Por qué importa
La señal no es que la privacidad esté de moda. Es que se está mudando de la página de términos al esquema de la respuesta.
El caso de GitHub es el aburrido y, justamente por eso, el más informativo. Según el changelog, este año restringieron los endpoints que listaban stargazers a administradores y colaboradores, y recién ahora ofrecen la alternativa: un agregado con marca temporal. Primero rompieron integraciones para sacar identidades de la respuesta, después repusieron la métrica que la gente realmente necesitaba. Ese orden dice todo. La privacidad ahí no depende de que nadie se porte mal: el dato identificable no viaja porque la API no lo devuelve.
El caso de Ollie es el opuesto en naturaleza. Con el material disponible tenemos una promesa —no entrenar, no compartir— y nada sobre cómo está sostenida. No hay en la nota detalle de cifrado, de inferencia local, de retención, ni de auditoría externa. Eso no la invalida, pero la ubica: es un compromiso de política sobre datos que el sistema sí recolecta y sí puede leer.
Qué cambia en la práctica
Si mantenés herramientas que graficaban crecimiento de estrellas, la migración es concreta y hay que hacerla: dejá de recorrer listas de stargazers y pedile al endpoint nuevo la serie histórica. Menos paginación, menos datos personales en tu base, menos superficie que justificar cuando alguien te pregunte qué guardás.
La lectura más útil, sin embargo, es de diseño. Cuando revisás tus propias APIs, la pregunta no es «¿tenemos permiso para devolver esto?» sino «¿el consumidor necesita la identidad o le alcanza el agregado?». En mi experiencia, la mayoría de los dashboards internos piden identidades por inercia: se armó el endpoint con el join más fácil y nadie volvió a mirarlo. Agregar en el borde, del lado del servidor, elimina una clase entera de incidentes en lugar de administrarla.
La distinción que conviene tener presente al evaluar cualquier producto que se venda como privado:
| Dimensión | Promesa de política | Forma del dato |
|---|---|---|
| Qué la sostiene | Términos de servicio y reputación | El esquema de la respuesta |
| Si hay una brecha | El dato existe y se filtra | No hay identidad para filtrar |
| Si cambia el dueño | Revisable con una actualización de términos | Requiere volver a exponer el campo |
| Verificable desde afuera | Difícil sin auditoría | Se ve en una sola llamada |
| Costo de implementarla | Bajo | Alto: rompe consumidores existentes |
La última fila explica por qué casi todos eligen la columna del medio.
Cuándo NO usarlo
Agregar no es gratis, y vender el agregado como solución universal es deshonesto.
- Perdés capacidades reales. Sin identidades no hacés soporte caso por caso, no rastreás abuso ni detectás patrones anómalos. Si tu producto dependía de saber quién marcó un repositorio para detectar inflado artificial de estrellas, el endpoint nuevo no lo reemplaza y no hay que fingir que sí. Ahí el camino es replantear la función, no migrar y esperar.
- No aplica al caso del asistente. Un asistente que organiza la vida de una familia necesita el detalle personal para servir de algo. No hay agregación posible: la decisión de diseño se corre a dónde vive el dato, cuánto tiempo y quién puede leerlo. Confundir los dos problemas lleva a soluciones que no protegen nada.
- Cuidado con tomar la promesa como garantía técnica. Con la información publicada no sabemos si Ollie cifra del lado del cliente, si corre inferencia local, ni si alguien externo verificó algo. Mientras eso falte, «no entrenamos con tus datos» es una decisión revocable: sobrevive a los términos actuales, no necesariamente a una adquisición o a un cambio de modelo de negocio. No es una acusación, es lo que el material provisto permite afirmar.
- Si tu modelo de datos no cambia, no lo anuncies. Ponerle «privacidad primero» al home mientras seguís guardando todo es la manera más rápida de quedar expuesto en el primer incidente.
Qué haría hoy
Migraría cualquier integración propia que todavía dependa del listado de stargazers, porque ya está restringida y ahora hay reemplazo. Después haría una pasada corta por nuestros endpoints internos buscando los que devuelven identidades donde alcanzaba un conteo, y empezaría por el que más consumidores externos tiene.
Sobre el asistente, esperaría. La categoría es interesante y la posición es sensata, pero antes de darle acceso al calendario y a las conversaciones de una familia quiero leer el detalle técnico: retención, borrado efectivo, subprocesadores y qué pasa con los datos si la empresa cambia de manos. Hasta entonces, lo que hay es una intención declarada, que es bastante más de lo que ofrecen otros y bastante menos que una garantía.