Estos son los terceros que tratan datos por cuenta nuestra para que el servicio funcione. Cada uno está atado por un contrato escrito que no es menos protector que nuestro Acuerdo de encargo, y nosotros seguimos respondiéndote por lo que hagan.
Esta página describe lo que corre hoy, no lo que pensamos correr. Donde algo no está, lo dice.
| Subencargado | Qué hace por nosotros | Qué toca | Dónde |
|---|---|---|---|
| Google LLC (Firebase, Google Cloud) | Autenticación, base de datos, almacenamiento de archivos, funciones, hosting y la copia analítica descrita abajo | Datos de cuenta, identificadores de pacientes, escaneos, video de la sesión, cuadros de movimiento, notas | Estados Unidos (nam5, us-central1) |
| Apple Inc. | Distribución de la app por App Store y TestFlight | Identificadores de cuenta, datos del dispositivo | Estados Unidos |
| Proveedor de cómputo GPU | Corre la reconstrucción pesada de una sesión: rastreo de marcadores, alineación de mallas, generación de exportaciones | Video de la sesión, escaneos y cuadros de movimiento, mientras dura el trabajo y su ventana de retención | Estados Unidos |
No publicamos el nombre del proveedor de cómputo GPU. Hace parte de cómo está construido el producto y nuestros competidores también leen esta página. Le damos el nombre por escrito a cualquier cliente que lo pida, bajo confidencialidad, y quien tenga una objeción razonable puede plantearla según la sección 6 del Acuerdo de encargo. Ocultar un nombre es una decisión comercial; ocultar la categoría, la finalidad o el lugar sería un incumplimiento, y eso no lo hacemos.
No hay red publicitaria, ni herramienta de marketing, ni plataforma de correo masivo, ni producto de soporte con acceso a datos de clientes. Cuando alguno llegue, llega primero a esta página, 30 días antes de encenderse.
Sí hay un sitio donde material de un paciente llega a un modelo generativo, y va en su propia sección más abajo en vez de quedar enterrado aquí.
Hay una segunda copia de los registros de sesión dentro de Google Cloud y preferimos ponerla en esta página antes que dejarla enterrada en un esquema.
Lo que se exporta hoy. Una extensión de Firebase envía a BigQuery (conjunto
firestore_export, región us) la colección metricas: una fila derivada por sesión con la
duración, el número de fotogramas, la calidad del rastreo, el modelo del aparato, la versión de la
app, la jurisdicción y si hay autorización de entrenamiento. El paciente, la sesión y la cuenta
aparecen como seudónimos calculados con una clave que vive del lado del servidor y no viaja a
BigQuery. No lleva nombres, ni alias, ni documentos, ni enlaces de almacenamiento, ni notas
clínicas, ni los escaneos o el video en sí.
Un seudónimo estable sigue siendo dato personal mientras exista la clave, y no lo vamos a llamar anónimo. Lo que consigue es que una consulta analítica no toque nunca el dato identificable.
Lo que se exportaba antes, y por qué cambió. Entre el 18 de febrero de 2026 y el 12 de
septiembre de 2026 lo exportado era la colección cruda sessions, que sí lleva adentro identificadores de
paciente y enlaces de descarga de sus archivos. Un enlace de descarga de Firebase es una
credencial: quien lo tiene, baja el archivo. Por eso el 12 de septiembre la exportación cambió de
colección.
Qué pasó con lo ya exportado. Los siete meses de historia se conservan —sirven para medir en qué se cae una captura y no se pueden reconstruir hacia atrás— en una tabla aparte, sin nombres, sin identificadores en claro y sin un solo enlace. La tabla cruda original está en retiro.
Lo que debes saber, de todo lo anterior:
Esto lo encontramos revisando esta página contra la infraestructura real antes de publicarla, y preferimos escribir esa frase a corregirlo en silencio.
La app puede convertir la foto de un paciente en un retrato estilizado para su ficha. Cuando un
profesional usa esa función, la fotografía se envía a la API de Gemini de Google
(generativelanguage.googleapis.com) y vuelve la imagen estilizada.
Esto va en su propia sección porque la foto de una cara es lo más identificable de todo el producto, y porque "usamos Google" no es una forma honesta de describir mandarle la cara de un paciente a un modelo generativo.
| Qué se envía | Una fotografía que el profesional tomó o eligió, reducida a 1024 px como máximo, y la instrucción de estilo |
| Qué no se envía | El nombre del paciente, sus identificadores, escaneos, video de sesión, ni nada de la historia |
| Destinatario | Google LLC, API de Gemini, Estados Unidos |
| Cuándo | Solo si el paciente marcó su casilla y además un profesional oprime el botón para él. Nunca ocurre solo |
| Finalidad | Un retrato para la ficha. Nada más: ni análisis, ni diagnóstico, ni entrenamiento nuestro |
| Resultado | La imagen estilizada se guarda con la historia del paciente y se borra con ella |
Lo que no sabemos y no vamos a fingir que sabemos: qué conserva Google de su lado y por cuánto tiempo lo gobiernan los términos de la API de Gemini y no nuestro contrato. Por eso esta función exige la casilla propia del paciente, que va aparte de la clínica y de la de entrenamiento y empieza apagada, y por eso el formato de autorización la nombra con todas sus letras.
Si prefieres que esto no ocurra nunca en tu consultorio, no marques esa casilla con ningún paciente. No cambia nada más del producto.
Si conectas tu cuenta de Google Drive, la app lee los archivos que tú eliges para traerlos al caso: escaneos, radiografías, lo que tengas ahí.
Eso no es un subencargado, y la diferencia importa: es tu cuenta, y leemos por instrucción tuya. Nosotros no guardamos una copia de tu Drive ni lo indexamos. Lo que sí conviene que sepas es que el permiso que Google nos pide es de solo lectura sobre tu Drive completo, porque es el único alcance que existe para esto; usamos únicamente lo que tú señalas, pero el permiso concedido es más ancho que el uso, y preferimos decírtelo.
Se revoca desde tu cuenta de Google, en la pantalla de aplicaciones con acceso, sin pedirnos permiso y sin que nada más deje de funcionar.
Todo está en Estados Unidos. La base de datos está en nam5 y las funciones en us-central1, y
ninguna de las dos regiones se puede mover después de crear el proyecto.
Lo decimos porque la versión honesta de "transferencias internacionales" para un cliente europeo no es una frase tranquilizadora sobre anclaje regional. Es: los datos de tus pacientes se tratan en Estados Unidos, bajo cláusulas contractuales tipo (módulo dos, responsable-a-encargado), con cifrado en tránsito y en reposo. Si necesitas que el dato se quede en Europa, hoy no podemos atenderte y no deberías firmar.
Cuando exportas un caso, generamos el archivo en el formato que pediste y te lo entregamos a ti. No le mandamos nada a esos proveedores.
| Proveedor | Qué generamos | Relación |
|---|---|---|
| Modjaw | Archivo .xml de movimiento |
Proveedor independiente. Sin contrato con nosotros. El archivo lo mueves tú |
| exocad GmbH | Paquete PLY/STL | Proveedor independiente. Sin contrato con nosotros. El archivo lo mueves tú |
| Smilecloud SRL | Archivo .xml de diseño de sonrisa |
Proveedor independiente. Sin contrato con nosotros. El archivo lo mueves tú |
Si subes un archivo exportado a una de esas plataformas, tu relación con ese proveedor se rige por los términos de ellos, no por los nuestros. El día que agreguemos un envío directo, ese proveedor pasa a la tabla de arriba y te avisamos 30 días antes.
No tenemos un Business Associate Agreement con el proveedor de cómputo GPU y, por lo tanto, hoy no aceptamos clientes que sean Covered Entities bajo HIPAA. La información de salud protegida (PHI) no debe pasar por el servicio. Es un límite que declaramos, no un riesgo que corremos.
Avisamos con al menos 30 días antes de agregar un subencargado que vaya a tratar material de
pacientes. Escribe a hola@toothprint.ai para entrar a la lista de avisos. Puedes objetar por
razones fundadas; si no logramos resolverlo, puedes terminar la parte del servicio afectada.
| Fecha | Cambio |
|---|---|
| 2026-09-11 | Versión 1.0. Conciliada contra la infraestructura real: se quitó una afirmación de anclaje regional que no era cierta, se quitaron proveedores que nunca se contrataron, y se agregaron el proveedor de cómputo GPU y la copia en BigQuery |
| 2026-09-12 | Versión 1.1. Se declaró el envío de la foto del paciente a la API de Gemini de Google, que la versión anterior negaba al afirmar que ningún tercero hacía inferencia de IA sobre material de pacientes |
| 2026-09-12 | Versión 1.2. La exportación a BigQuery cambió de la colección cruda de sesiones a una colección derivada sin identificadores; la historia ya exportada se conserva seudonimizada |
Actualizado el 12 de septiembre de 2026 · Versión 1.2
Versión 1.1, modificada el 12 de septiembre de 2026. La versión 1.0 se publicó el 11 de septiembre y contenía afirmaciones que una revisión contra el sistema real demostró falsas. Se corrigen aquí en vez de editarse en silencio, porque un documento publicado que cambia sin decirlo vale menos que uno que reconoce que cambió: una página que decía que ningún tercero hacía inferencia de IA sobre material de pacientes, mientras una función de foto mandaba caras a un modelo generativo; una página de seguridad que afirmaba recuperación a un punto en el tiempo y respaldos de 12 meses que nunca se configuraron; una promesa de borrado con un solo plazo para tres destinos que no van a la misma velocidad; y una promesa de destrucción a tres años sin nada debajo.
Versión 1.2, modificada el 12 de septiembre de 2026. La exportación analítica a BigQuery dejó de llevar la colección cruda de sesiones —que lleva adentro identificadores de paciente y enlaces de descarga, y un enlace de descarga es una credencial— y pasa a llevar una colección derivada sin nada identificable. La historia ya exportada se conserva aparte, seudonimizada. Se escribe aquí porque la versión 1.1 describía la exportación anterior y describirla mal, después de arreglarla, sería el mismo error de la versión 1.0 al revés.