ESTOYAI
La ONG hace el trabajo. EstoyAi lo deja escrito.
Sistema de registro de campo por voz para ONGs de territorio: el promotor dicta la visita, la IA local genera un informe .docx y coordinación lo ve priorizado por criticidad. Offline-first. Ningún dato sale de la sede.
Del audio de una visita a un informe archivable, en unos 5 minutos.
TL;DR
La tesis: entre una ONG de nutrición y una de tratamiento de consumos, lo único que cambia es el esquema de datos. No estás construyendo una solución para una ONG, estás construyendo infraestructura para el sector.
01. Problema
Las ONGs de territorio registran en cuadernos, WhatsApp y Excel. Alguien tiene que pasar todo a la computadora a mano. Son horas de trabajo, y aun así es casi imposible ver qué caso necesita atención primero.
02. Insight
El cuello de botella no está en la intervención, sino en el registro: ocurre donde no hay red, y lo urgente queda enterrado. Resolver la captura destraba todo lo demás.
03. Solución
Registro por voz offline-first: el promotor dicta, la IA local transcribe y genera un .docx, y coordinación lo ve priorizado por criticidad. Todo corre en la PC de la sede.
04. Estado
MVP funcional, diseñado y construido en solitario después del hackathon. Validé el problema con la dirección de la ONG, no el flujo completo con un promotor en un día real. No validado en uso real todavía: ese es el próximo paso, no un dato que ya tenga.
De dónde viene
El punto de partida fue Halketon (jun 2026), un hackathon organizado por Paisanos, Crecimiento, Querido Lunes y Fardo para construir herramientas reales para organizaciones sociales argentinas.
Los organizadores entrevistaron a 16 ONGs y agruparon los hallazgos en tres tracks. 13 de esas 16 caían en el Track 3 (impacto y reportes). No logran registrar su trabajo de campo de forma sistemática, y el patrón se repetía siempre igual (cuadernos, WhatsApp y planillas). Mientras la información vive en papel, la coordinación no tiene cómo ver qué pasó en territorio ni detectar a tiempo un caso urgente.
El piloto: Pequeños Pasos
De ahí salió Pequeños Pasos como caso piloto: una ONG con promotores en territorio, varios programas de seguimiento de familias y carga administrativa real. La restricción que define todo lo demás es que trabajan en zonas sin señal. Validé el problema con su directora durante el evento, y esa conversación confirmó el dolor y fijó los límites técnicos.
Para ser preciso con el alcance: en Halketon lideré producto y coordinación en un equipo de cuatro que armó un prototipo en 12 horas. El sistema instalable, multi-tenant y offline-first que ves acá lo diseñé y construí solo después del evento. Fue una reconstrucción completa, no una iteración del prototipo. Ese salto es el eje del caso.
16
ONGs entrevistadas en el relevamiento de Halketon
13 de 16
manifestaron el problema del Track 3: registro de campo sin sistematizar
< 5 min
meta de diseño: del audio de la visita al .docx (estimación, no medida)
$0
gratis y open source (MIT), sin licencias ni nube
Fuente: relevamiento de Halketon (Paisanos · Crecimiento · Querido Lunes · Fardo) a 16 ONGs argentinas, abr–may 2026. El proyecto tomó el Track 3 (impacto y reportes) con Pequeños Pasos.
El problema real
El cuello de botella de las ONGs de territorio no está en la intervención, sino en el registro de lo que hacen. Cuatro fricciones que se repiten:
El registro ocurre donde no hay red
Un promotor que visita a una familia en zona vulnerable no puede abrir un formulario online. Lo que no anota en el momento se reconstruye después de memoria, con sesgo y omisiones.
El historial del beneficiario está fragmentado
Una misma persona puede tener datos en un cuaderno, en un grupo de WhatsApp y en una planilla que nadie actualizó hace meses. Seguir su evolución en el tiempo es imposible.
Digitalizar lo de campo consume horas
Pasar a la computadora lo que se anotó en papel es trabajo manual de alguien que no estuvo en la visita. Horas que se van en transcribir en vez de acompañar.
Lo urgente queda enterrado
Aunque la información se cargue, encontrar el caso que necesita atención inmediata entre decenas de registros es lento y depende de que alguien lo recuerde. La coordinación se entera tarde.
El resultado: equipos que dedican horas a transcribir en vez de acompañar, y una coordinación sin visibilidad de lo que ocurre en territorio hasta que ya es tarde.
Cómo funciona
Del campo a la sede sin que nadie digitalice nada a mano. El audio viaja, la IA local lo procesa, y el trabajo de campo se vuelve una decisión.
Dicta 2 min
Celular, sin señal
Se encola
IndexedDB → sube con red
Whisper + Ollama
Transcribe y extrae campos
Informe generado
Estructura fija, editable
Triaje
Criticidad + accionables
Todo el procesamiento (transcripción, IA y almacenamiento) corre en la PC de la sede. Sin APIs externas, sin nube, sin GPU.
En acción
El flujo real corriendo, con la configuración de Pequeños Pasos y datos de ejemplo. Del dictado en el celular al informe priorizado en la sede.
- 1
Dictar la visita
unos dos minutos de voz, sin señal, con waveform en vivo
- 2
Cola offline
el audio se encola y sube solo cuando hay red
- 3
Informe .docx
queda listo para revisar y enviar a coordinación
UI real corriendo en local. El .docx final y la transcripción usan el stack completo en la sede.
Las tres pantallas del promotor, en el celular. El tablero que ve coordinación llega más abajo.
Priorización por criticidad
El sistema no se queda en generar el .docx. La IA le asigna a cada informe un nivel de criticidad y extrae el motivo y las acciones pendientes. Ese es el paso que convierte un montón de informes en una decisión: qué atender primero.
El criterio
Emergencia o riesgo inminente
Exige acción el mismo día y activa un protocolo. El eje no es la gravedad en abstracto sino el tiempo para actuar: riesgo de vida por salud aguda, indicios de violencia o abuso, un menor sin adulto responsable presente.
Seguimiento en los próximos días
Necesita gestión pronta pero no es una emergencia: controles de salud atrasados, ausentismo escolar, riesgo de abandono del programa. Queda una acción pendiente con fecha cercana, no un protocolo.
Rutina, evolución esperada
Seguimiento habitual con buena evolución y sin acciones pendientes. Entra igual al sistema: el historial se construye con todo, no solo con lo urgente. Pero no compite por la atención del equipo.
Una red de seguridad sobre la IA
La IA corre local y el modelo es chico: puede omitir algo. Por eso la criticidad no depende solo del modelo. Una red de seguridad por palabras clave fuerza ALTA ante términos de riesgo explícito (violencia, golpes, autolesión, un menor solo). El principio, transferible a cualquier producto con IA: cuando el modelo decide algo con consecuencias reales, el diseño necesita un piso que no dependa del modelo.
Límite conocido: si el modelo omite una ALTA que no cae en ninguna keyword, puede pasar desapercibida. Por eso la transcripción completa queda siempre disponible y el promotor revisa y ajusta la prioridad antes de enviar a coordinación. La decisión final de prioridad siempre queda en una persona.
La IA propone, una persona confirma
Antes de enviar a coordinación, el promotor abre la pantalla de revisión: puede corregir la prioridad (Alta / Media / Baja), el motivo, el resumen y los accionables, ver la transcripción completa y elegir qué secciones entran al .docx. La criticidad que asignó el modelo es un punto de partida editable, no una decisión automática sin control humano.
El tablero de coordinación
Coordinación abre el tablero desde la PC de escritorio de la sede, la misma máquina que corre Docker. Los informes se agrupan por criticidad y arriba “necesita atención hoy” separa dos cosas que no son lo mismo: la criticidad clínica (ALTA) de los errores técnicos del pipeline. No es igual llamar a una familia que reintentar un informe que falló. La meta es saber en 10 segundos qué atender primero.
Acá se cierran los dos momentos de control humano: para cuando coordinación abre el tablero, la prioridad de cada caso ya pasó por una persona. Nadie está mirando un triaje que decidió el modelo solo.
Quién ve y quién edita
Los dos roles no comparten ni pantalla ni permisos. El promotor trabaja desde el celular, en campo. Coordinación (administrativos y dirección) trabaja desde la PC de escritorio de la sede. Enviar a coordinación es la frontera entre los dos mundos.
- Mis registros · sus borradores. Los edita y los borra, pero solo hasta enviarlos.
- Informes del equipo · los ve, no los toca. Sin editar ni borrar, ni siquiera los propios.
- Mis registros · sin acceso. Los borradores ajenos no existen para coordinación.
- Informes del equipo · los edita y los borra. Es el único rol que puede.
El borrador es privado a propósito: mientras el registro está a medio revisar es del promotor y de nadie más, y coordinación no ve versiones intermedias. Enviar es el punto de no retorno, y por eso la pantalla de revisión existe antes y no después.
Elegir el modelo fue una decisión de producto
La tensión real no era “qué modelo es más inteligente”, sino qué calidad de clasificación se puede sostener en el hardware que una sede realmente tiene. Evalué los modelos contra una rúbrica de 9 transcripciones (una por prioridad × programa) y el fallo estaba en el modelo, no en el prompt:
| Modelo | Rúbrica | Veredicto |
|---|---|---|
| gemma3:1b | 4/9 | Descartado, se le escaparon casos graves (ej. maltrato infantil) |
| gemma3:4b | 8/9 | Elegido, default de producción. ~16 GB RAM, sin GPU |
| gemma3:12b | 9/9 | Mejor calidad, pero pide PC potente (≥ 24 GB) |
gemma3:4b quedó como default. Es el piso de calidad y corre en una PC de escritorio con ~16 GB de RAM, sin GPU ni nube. Con 8 GB queda chico y el modelo tilda la máquina. El 12b (9/9) rinde mejor pero pide un equipo más potente (≥24 GB). En hardware más limitado se baja a un modelo liviano (gemma3:1b / qwen3:1.7b), con un costo real de precisión que amortigua la red de keywords. Es un eval chico (9 transcripciones) y todavía sin correr sobre el hardware real de una sede, así que lo trato como criterio de decisión, no como benchmark cerrado.
Por qué estas decisiones
EstoyAi fue diseñado desde las restricciones de las ONGs de territorio, no a pesar de ellas. Cada decisión responde a una realidad concreta del campo.
Por qué offline-first
Los promotores visitan zonas sin señal. Un formulario que pide internet en el momento no se usa. El audio se graba y sube solo cuando hay conexión. El promotor no hace nada más.
Por qué Word y no una app propia
Coordinadores y trabajadores sociales ya usan Word. Sin capacitación, sin pantalla nueva. El .docx es editable, imprimible y auditable por cualquiera. Una app propia sumaría una dependencia y dejaría afuera a quien prefiere el papel.
Por qué no un CRM
Las ONGs ya probaron Asana, Notion, Salesforce, Trello, y los dejaron. El cuello de botella no es la coordinación sino el registro de campo. Si los datos no entran fácil, el CRM queda vacío igual. EstoyAi resuelve la captura, lo demás lo decide cada ONG.
Por qué SQLite local y no un backend en la nube
Un Supabase pondría los datos de beneficiarios en un servidor ajeno, lo contrario del modelo. SQLite guarda todo en un archivo en la PC de la sede, sin servicio externo ni credenciales. Para una sola sede sobra, y no agrega una dependencia de red que no hace falta.
Instalación, datos e integraciones
Tres decisiones de build más chicas, con la misma lógica: cada una sale de una restricción de la sede, no de una preferencia técnica.
Un instalador, no un despliegue
Un instalador guiado (Inno Setup) levanta todo el stack en Windows, sin línea de comandos. La sede instala y usa, no administra.
Backup a un disco, no a la nube
El backup va a un disco externo. Consideré un bucket R2, pero el free tier se llenaba con los audios y subir datos sensibles contradice el modelo. Google Drive, lo mismo.
Integración opcional con Podio
Para las ONGs que ya usan Podio hay un endpoint que empuja el .docx vía n8n. Opcional: nadie cambia de herramienta.
Los datos no salen de la sede
El diferencial no es solo técnico: es una postura ética. Los datos de beneficiarios, muchas veces menores y familias vulnerables, son lo más sensible que maneja una ONG. EstoyAi los trata en consecuencia.
Procesamiento local
Whisper, Ollama y el almacenamiento corren en la PC de la ONG. Ningún audio ni dato pasa por servidores externos.
Auditable porque es abierto
El código es público (MIT): para una ONG, eso no es cosmético, es seguridad. Cualquier persona técnica de confianza puede verificar que los datos no se copian ni se envían a ningún lado. La privacidad no es una promesa, es inspeccionable.
Sin dependencias de nube
Sin suscripciones a APIs de IA ni de transcripción. Si la PC se apaga, el sistema se apaga: la sede tiene control total (y es también un punto único de falla, ver límites al cierre).
Diseñado sobre la Ley 25.326
Tomé la ley argentina de protección de datos personales y los derechos de los titulares como marco para el modelo de datos y los controles. Es una decisión de diseño documentada, no una certificación de cumplimiento.
TODO EN LA PC DE LA SEDE · DOCKER
Celulares
PWA offline
app-pwa
PWA + API
n8n
orquestación
faster-whisper
transcripción
Ollama · gemma3:4b
extracción IA
SQLite + .docx
datos e informe
El audio entra por el túnel a la sede. La transcripción, la IA, la base de datos y la generación del .docx ocurren en la misma máquina, todo dentro de Docker. Nada sale de ahí. Se instala con un instalador guiado, sin línea de comandos.
Un sistema, muchas ONGs
EstoyAi no está atado a un tipo de intervención. Es multi-tenant por subdominio: cada organización corre su propia configuración sobre el mismo código. El piloto de referencia es Pequeños Pasos, y armé una segunda configuración deliberadamente opuesta para poner la hipótesis a prueba.
La hipótesis del arranque no quedó en el pitch, definió dónde pasa la línea del código. Programas, campos del informe y schema de extracción viven en un archivo de configuración por tenant. La captura por voz, la cola offline, el pipeline local y el triaje por criticidad son núcleo compartido y no se tocan.
Sumar una organización nueva es escribir un archivo de configuración y levantar un subdominio. No es un fork ni una rama por cliente, que es donde este tipo de sistemas suele terminar.
Pequeños Pasos
PILOTOONG de intervención territorial · pequenospasos.estoyai.com
La organización con la que se diseñó el sistema, con tres programas de seguimiento de familias.
DTC Villa Tranquila
PRUEBA DE CONCEPTOModelo SEDRONAR de tratamiento de consumos
No es una segunda ONG a bordo. Es la prueba de la hipótesis: armé la configuración de una intervención en las antípodas de una visita de nutrición y la contrasté contra mi propia experiencia trabajando en el modelo SEDRONAR de tratamiento de consumos. El núcleo se sostuvo sin tocar una línea.
La misma pantalla y el mismo código en los dos tenants. Cambian solo los programas y los campos del informe, por configuración.
Cómo entra una ONG nueva
Diseñé una landing pública para que una organización pueda evaluar el sistema sin hablar conmigo primero. Es la puerta de entrada del modelo de adopción: si la tesis es que sirve para muchas ONGs, tiene que poder llegar a ellas sin que yo esté en el medio.
Cada sede después usa la app por su propio subdominio (pequenospasos.estoyai.com, dtcvillatranquila.estoyai.com) y entra con una contraseña que solo tiene su equipo.
Estado y qué sigue
Hoy EstoyAi es un MVP funcional, diseñado y construido en solitario después del hackathon. Validé el problema con la dirección de Pequeños Pasos, pero todavía nadie de una ONG usó el flujo completo en un día laboral real. El sistema está disponible para cualquier organización que quiera adoptarlo.
Límites conocidos
- Validé el problema con coordinación, no el comportamiento con un promotor: todo el producto depende de que efectivamente dicte 2 min al terminar la visita, y eso todavía no lo observé con nadie.
- Calidad de transcripción en campo: audio de celular, ruido y tonada rioplatense son el mayor riesgo técnico. Es un frente abierto que hay que medir con audio real.
- Disponibilidad vs. durabilidad. Si la PC de la sede muere, el servicio se cae: es el precio de que nada salga de la sede, no algo que se pueda “mitigar” sin traicionar el modelo. Los datos, en cambio, sí están cubiertos con backup manual a un disco externo. No auto-enviarlos a la nube es una decisión deliberada: los endpoints a R2 existen en el código pero quedan fuera del producto, por la misma razón de privacidad.
Próximo paso real
Poner el flujo completo en manos de un promotor y una coordinadora durante un día de trabajo, y medir lo único que valida el producto: ¿se usa sin mí al lado?, ¿el .docx es lo que el financiador pide?, ¿cuánto tiempo ahorra de verdad frente al cuaderno?
Qué haría distinto: llegar antes a esa sesión con la ONG, sin esperar a “tenerlo todo”. La lección de este proyecto es que el validador no es un examen final al que llegar listo, es una dependencia del roadmap.
Sin señal, sin presupuesto, sin equipo técnico, con datos que no pueden salir. Diseñar desde esas restricciones no fue una limitación. Fue el producto.
