Construí una Herramienta de Farmacogenómica en 12 Minutos. No la Usaría.
Sesenta millones de personas tienen datos genéticos que podrían cambiar cómo su médico les receta. La herramienta para traducir esos datos existe y tardó minutos en construirse. Pero la verdadera pregunta no es "¿podemos construirla?" — es "¿por qué confiarías en ella?" La respuesta apunta a un cambio fundamental en lo que el software se está convirtiendo.
8 min read
Construí una herramienta de farmacogenómica un domingo por la mañana. Tardé doce minutos.
Subes tu archivo de datos brutos de 23andMe — ese que lleva en tu carpeta de Descargas desde 2019 — y te dice qué fármacos comunes podrían no funcionar para tu genotipo. Clopidogrel después de un stent. Codeína para el dolor. Simvastatina para el colesterol. Mapea tus alelos star a las guías clínicas publicadas y genera un PDF de una página que puedes entregar a tu médico de cabecera.
El caso clínico es sólido. El ensayo PREPARE — siete países europeos, 6.944 pacientes — demostró que la prescripción guiada por farmacogenómica redujo las reacciones adversas a medicamentos en un 30%. Cada año, se recetan a personas fármacos que su genoma dice que no funcionarán — o peor, que les harán daño. Los datos para prevenir esto están en sesenta millones de discos duros. Las guías clínicas están publicadas, revisadas por pares y son de libre acceso. La brecha entre capacidad y despliegue es pura fontanería.
Así que le dije a mi agente de IA que construyera la herramienta. Delegó a un modelo de programación. Doce minutos después: una aplicación funcional. Cinco genes, llamado de alelos star, informe semáforo, PDF para el clínico. Todo del lado del cliente — tus datos genéticos nunca salen de tu navegador.
Y no la usaría.
El Problema de Confianza Que No Se Puede Resolver con Ingeniería
Nominalmente soy el autor de esta herramienta. Especifiqué lo que debía hacer. Revisé los resultados de los tests. Verifiqué que compila. Pero no he leído cada línea de la lógica de llamado de alelos star — el código que decide si eres un metabolizador pobre de CYP2D6, lo que determina si la codeína podría causar depresión respiratoria fatal en tu hijo.
Eso no es un detalle menor que estoy pasando por alto. Ese es todo el punto.
El viejo modelo de confianza en el software funcionaba así: una empresa construye algo, pone su marca detrás, obtiene aprobación regulatoria, y tú confías en la institución. GeneSight cobra 250 dólares por un test farmacogenómico. Confías en él porque Myriad Genetics es una empresa cotizada en bolsa con autorización de la FDA y seguro de responsabilidad profesional. La confianza es institucional.
La nueva realidad es: una persona con un agente de IA puede construir la herramienta equivalente en una tarde. El código funciona. Los tests pasan. La lógica clínica se basa en las mismas guías publicadas que usa GeneSight. Pero no hay institución detrás. Sin revisión regulatoria. Sin seguro de responsabilidad. Solo código fuente en GitHub y una afirmación de que "tus datos nunca salen de tu navegador."
¿Por qué confiarías en esa afirmación? ¿Porque yo lo digo? No me conoces. ¿Porque el código es open source? No lo has leído. La mayoría de la gente no puede leerlo. "Open source" es una señal de confianza para desarrolladores. Para todos los demás, es una frase de marketing.
Software como Receta
Esto es lo que creo que realmente está cambiando.
Estamos pasando de software como producto a software como receta. Un producto es algo que consumes — confías en la marca, aceptas la caja negra, haces clic en "Acepto" en la política de privacidad que nadie lee. Una receta es algo que verificas, modificas y ejecutas en tu propia cocina.
Ahora mismo, casi nadie puede hacer esto. Leer código fuente es una habilidad especializada. Ejecutar un servidor de desarrollo local requiere conocimientos técnicos que la mayoría no tiene. La idea de "audita el código tú mismo" es técnicamente correcta y prácticamente inútil para el 99% de la población.
Pero ese 99% está cambiando, rápido.
Cada vez más gente tendrá agentes — asistentes de IA con los que habrán construido cierta relación de confianza — que pueden auditar código fuente en su nombre. No perfectamente. No infaliblemente. Pero lo bastante bien para detectar los problemas obvios: ¿Este código realmente procesa datos del lado del cliente, o los envía silenciosamente a un servidor? ¿La lógica de alelos star coincide con las guías CPIC publicadas? ¿Hay peticiones de red en el código que no deberían estar ahí?
El flujo no es "confía en el sitio web." El flujo es:
- Aquí está el código fuente
- Descárgalo
- Pídele a un agente en el que confíes que lo audite
- Ejecútalo localmente en tu propia máquina
No todo el mundo hará esto. Pero no hace falta que lo haga todo el mundo. Necesitas una masa crítica de agentes haciendo verificación para que el ecosistema se autocontrole — igual que funciona hoy la seguridad open source, excepto que los auditores son IA y la barrera de entrada para auditar baja de "años de experiencia en programación" a "pregúntale a tu agente."
El Excedente Dentro del Excedente
La herramienta de farmacogenómica demuestra un excedente: los datos existen, las guías existen, la tecnología es trivial, y sin embargo sesenta millones de personas no pueden traducir fácilmente sus datos de genotipo en algo que su médico pueda usar.
Pero el problema de la confianza demuestra un segundo excedente, más profundo: no tenemos la infraestructura de verificación para un mundo donde cualquiera puede construir software de grado clínico en una tarde.
Ahora mismo, el marco regulatorio de la FDA asume que el software viene de empresas. La 21st Century Cures Act creó una exención para herramientas de Apoyo a la Decisión Clínica, pero la exención asume un autor institucional con procesos de cumplimiento. Cuando el autor es "un tío con un agente de IA," el marco no sabe qué hacer.
La respuesta no es regular a los creadores individuales hasta sacarlos del juego — eso congelaría el excedente en su sitio. La respuesta es cambiar el modelo de confianza de la verificación del autor (¿quién construyó esto?) a la verificación del artefacto (¿qué hace realmente este código?). Agentes que puedan auditar. Estándares sobre qué significa "auditado por IA." Un nuevo tipo de transparencia donde el código fuente ES la confianza, porque los agentes hacen legible el código fuente para todos.
Aún no estamos ahí. Pero la brecha entre "cualquiera puede construirlo" y "cualquiera puede verificarlo" se está cerrando más rápido que la brecha entre "es posible" y "está desplegado." El excedente de verificación podría cerrarse antes que el excedente de despliegue.
Lo Que Realmente Recomiendo
Si tienes un archivo de datos brutos de 23andMe y quieres saber sobre tu perfil farmacogenómico:
No lo subas a mi web.
En serio. Clona el repositorio. Lee el código, o pídele a un agente en el que confíes que lo lea. Ejecútalo en tu propia máquina. La herramienta son unos cientos de líneas de TypeScript — la lógica de llamado de alelos star es una tabla de búsqueda, no una caja negra. Un agente puede auditar todo en segundos.
Si encuentras un bug — especialmente en la lógica de llamado de alelos — abre un pull request. Así funciona este modelo. La herramienta mejora no porque una empresa tenga un departamento de control de calidad, sino porque una red distribuida de agentes puede verificar más rápido de lo que cualquier empresa puede testear.
¿Y si la lógica de llamado de alelos resulta estar mal? Ese es precisamente el punto. Es inspeccionable. Es corregible. Es una receta, no un producto. El código es la confianza.
El excedente de la farmacogenómica es real. Los datos están en sesenta millones de discos duros. Las guías están publicadas. La herramienta se puede construir en minutos. Pero la intervención real no es la herramienta — es la infraestructura de confianza que permite a la gente usar herramientas como esta de forma segura. Esa infraestructura se está construyendo ahora mismo, una receta auditable a la vez.
El código fuente de RxLens está disponible en github.com/willworth/rxlens. La lógica de llamado de alelos star está en src/lib/pgx-engine.ts. Las guías CPIC que referencia están en cpicpgx.org. Si tu agente encuentra un problema con el código, por favor abre un issue.