De una nueva ley a una oportunidad de producto
Cómo una investigación sobre la Ley 21.719 terminó revelando un problema de continuidad en la evaluación hipotecaria: no basta con corregir un dato, hay que lograr que deje de producir la consecuencia que originó el caso.
Objetivo
Descubrir si la Ley 21.719 abría una oportunidad de producto capaz de producir dos resultados simultáneos: que una persona pudiera continuar su camino hacia la vivienda y que el banco recuperara una colocación hipotecaria viable que estaba en riesgo por una falla de coordinación de datos.
- Estrategia
- Discovery end-to-end, JTBD, benchmark y experimentación
- Diseño
- Product Strategy, UX, propuesta de valor y prototipado
- Contexto
- Proyecto académico · Unegocios FEN · Universidad de Chile
Dos outcomes conectados por un mismo quiebre
La persona quiere su casa. El banco quiere concretar un hipotecario viable.
Un dato incorrecto puede bloquear ambos resultados. Ruta Segura conecta la corrección con el reingreso a evaluación para que el caso no se cierre administrativamente mientras la oportunidad real todavía sigue viva.
Caso de discovery · Ruta Segura
La entrada en vigencia de la Ley 21.719 de Protección de Datos Personales abría un nuevo escenario en Chile. Mientras gran parte de la industria se preparaba desde compliance, trazabilidad y riesgo regulatorio, el desafío fue mirar el cambio desde el lado de las personas: ¿qué pasa cuando un dato que una organización tiene sobre mí empieza a afectar una decisión importante?
No partimos con banca, una solución ni un usuario definido. Partimos con una regulación, un conjunto de derechos y una pregunta incómoda: ¿hay un problema suficientemente relevante como para que alguien quiera actuar y para que una organización quiera financiar una solución?
El punto de partida no era un producto
La conversación sobre datos personales suele comenzar en el lugar equivocado. Se habla de consentimientos, políticas, registros y cumplimiento; pero para una persona el problema aparece en otro momento: cuando un dato vuelve a aparecer después de haber sido corregido, activa un cobro que no reconoce, explica un rechazo o participa en una decisión que nadie sabe traducir.
La ley fortalecía derechos como acceso, rectificación, supresión, oposición y portabilidad. Eso abría posibilidades, pero no demostraba que las personas conocieran esos derechos, entendieran cómo ejercerlos o estuvieran dispuestas a dedicar tiempo a perseguir una respuesta entre distintas instituciones.
Por eso el encargo no era diseñar una interfaz de privacidad. Era convertir una señal regulatoria en un caso defendible: entender el problema, encontrar a quién le ocurre, identificar el momento de activación, ubicar el valor y comprobar si existía una lógica de negocio razonable.
El desafío: saber si había “agua en la piscina”
La pregunta inicial era deliberadamente amplia. No sabíamos si el espacio estaba en educación, visualización, gestión de derechos, seguridad, fraude, banca o atención al cliente. Tampoco sabíamos quién sería el usuario principal, quién capturaría valor ni quién pagaría.
Había que evitar una trampa habitual: tomar la existencia de una ley como prueba de que existe una oportunidad de producto. Una regulación puede crear obligaciones para las organizaciones sin crear, por sí sola, una conducta frecuente en las personas. También puede hacer visible un problema sin indicar todavía cuál es la solución ni el modelo económico.
El discovery debía responder cuatro preguntas:
- Activación: ¿qué situación hace que una persona deje de tolerar la falta de control?
- Fricción: ¿en qué momento se pierde entre canales, responsables y respuestas parciales?
- Resultado: ¿qué significa realmente que el problema esté resuelto?
- Valor: ¿quién obtiene suficiente beneficio como para sostener el servicio?
Investigar antes de elegir el segmento
La investigación combinó desk research, benchmark, revisión del marco regulatorio, construcción de hipótesis y tensionamiento de escenarios. El propósito no era llenar un canvas, sino hacer que cada recorte tuviera una razón y que cada afirmación tuviera un nivel de confianza explícito.
El material distinguía entre contexto, evidencia limitada, síntesis e inferencia. Esa distinción fue importante porque todavía no existía una validación específica en banca: contábamos con investigación general y escenarios de tensión, pero no con una base suficiente para afirmar que los hipotecarios eran el segmento definitivo.
En consecuencia, el proyecto avanzó con una hipótesis de trabajo, no con una verdad cerrada. La banca y el crédito fueron el contexto elegido para hacer concreto el problema y permitir una evaluación más exigente de urgencia, coordinación y valor.
Lo que el desk research hizo visible
El problema no parecía ser solamente que las organizaciones tuvieran datos. Era que, una vez que los datos circulaban, la persona perdía visibilidad sobre su origen, su uso, las relaciones que explicaban una decisión y el lugar exacto donde debía pedir una corrección.
Una organización puede cruzar información para inferir identidad, hábitos, situación financiera, salud o relaciones. La persona, en cambio, suele recordar que entregó un dato, pero no todos los sistemas donde terminó, las reglas que lo transformaron ni las decisiones en las que pudo influir. Ahí aparece una asimetría de contexto: la organización acumula una historia; la persona recibe una consecuencia.
El marco legal abre derechos y obligaciones, pero no resuelve automáticamente la experiencia. La persona todavía necesita entender qué ocurre, saber ante quién actuar, completar una solicitud, demostrar lo que sostiene y comprobar que la respuesta tuvo efecto en el sistema que originó el problema.
“No sé quién tiene mi RUT”.
“Me siguen llamando aunque pedí que dejaran de hacerlo”.
“Me cobran una deuda pagada, ajena o inexistente”.
Las frases cambian, pero la fricción se repite: la persona no tiene un hilo confiable para llegar desde la consecuencia hasta el cierre.
El principal hallazgo: la urgencia aparece con la consecuencia
La oportunidad no estaba en crear otro dashboard para administrar privacidad. Un panel puede ayudar a visualizar información, pero no necesariamente ayuda a resolver una consecuencia concreta ni a coordinar a las instituciones que intervienen en ella.
La necesidad aparecía cuando un dato dejaba de ser abstracto: un cobro desconocido, una deuda incorrecta, un fraude, un rechazo o una decisión difícil de explicar. En esos momentos la persona no quiere convertirse en auditora permanente de su historial. Quiere entender qué pasó, saber qué hacer y tener certeza de que el problema terminó.
“Quiero controlar mis datos”.
→ “Un dato está afectando algo importante y necesito resolverlo”.
Ese cambio de formulación modificó todo el espacio de búsqueda. El producto ya no tenía que organizar información por la información misma; tenía que reducir la distancia entre una anomalía y su resolución verificable.
El espacio se fue reduciendo
El recorte no ocurrió de una vez. Cada paso eliminó una propuesta demasiado amplia y acercó la investigación a una decisión concreta:
Ley 21.719 → control de datos → anomalías → banca → crédito → evaluación hipotecaria.
El contexto hipotecario resultó especialmente útil porque reúne tres condiciones: una decisión de alto impacto para la persona, una ventana de evaluación limitada y varios actores que operan con registros que no necesariamente se actualizan al mismo tiempo.
El momento crítico: corregir no es lo mismo que retomar
Para tensionar la oportunidad, imaginamos un caso en el que una persona está solicitando un crédito hipotecario. El banco detecta una deuda que la persona entiende que ya pagó. Ella contacta a la institución que informó el dato, entrega comprobantes y obtiene una respuesta: el registro fue corregido.
Sin embargo, la evaluación del banco puede seguir mostrando la versión anterior. La actualización puede llegar después, quedar en otra fuente o no estar vinculada con el expediente que el banco utiliza para decidir. La persona vuelve al banco; el banco la deriva; la institución reportante confirma que hizo su parte. Cada actor resuelve un tramo, pero nadie es responsable de demostrar la continuidad completa.
Ese vacío es el problema. No termina cuando una institución dice “corregido”. Termina cuando el dato deja de producir la consecuencia que originó el caso y la persona puede retomar una operación que todavía era viable.
La síntesis del caso lo expresa así: una vivienda viable, una deuda ya pagada y una evaluación detenida. La deuda es el dato visible; la discontinuidad entre sistemas es la fricción estructural.
Dos personas con outcomes distintos
Una decisión importante del proyecto fue no hablar de “el usuario” y “el beneficio” como si fueran únicos. La persona y el banco participan en el mismo flujo, pero no buscan exactamente lo mismo.
La solución no se justifica porque “ayuda a ambas partes” de forma genérica. Se justifica si logra conectar esos outcomes sin confundirlos: la persona busca continuidad para alcanzar su vivienda; el banco busca continuidad operativa para concretar una operación que puede beneficiar a ambas partes.
La oportunidad de producto: Resolución Verificada
El concepto que terminó estructurando la propuesta fue Resolución Verificada. No significa solamente que se ingresó una solicitud, que una institución contestó o que un dato cambió en un sistema. Significa que existe evidencia suficiente para conectar el caso original con el efecto esperado.
En el escenario hipotecario, una Resolución Verificada necesita responder cuatro preguntas:
- Origen: ¿qué institución reportó el dato y qué registro estaba produciendo la consecuencia?
- Corrección: ¿qué se solicitó, con qué antecedentes y quién confirmó el cambio?
- Propagación: ¿la actualización llegó a la fuente o evaluación que seguía mostrando el problema?
- Continuidad: ¿el banco pudo retomar el análisis con información correcta dentro de la ventana disponible?
Así, el outcome no es “tener un trámite cerrado”. Es que la corrección se vuelva efectiva en el contexto donde la persona necesita que produzca un cambio.
La solución: una capa de coordinación
Ruta Segura propone una capa de coordinación entre la persona, la institución responsable del dato y el banco evaluador. La persona relata su problema una vez y entrega sus antecedentes. El sistema estructura el caso, identifica responsables, mantiene visibles los estados y reúne evidencia hasta alcanzar un cierre.
La propuesta no busca reemplazar los sistemas existentes ni crear otro registro financiero. Busca mantener un solo hilo de evidencia:
anomalía → relato → orientación → solicitud → responsable → gestión → evidencia → reingreso
El rol de la IA tampoco es “hacer magia” ni decidir por las instituciones. Puede ayudar a traducir un relato desordenado en un caso accionable, detectar información faltante, identificar el derecho o canal probable, explicar una respuesta difícil de entender y sugerir el siguiente paso. La decisión, la autorización y la responsabilidad siguen perteneciendo a las personas y organizaciones involucradas.
El primer MVP no necesita APIs perfectas para aprender. Puede funcionar como un servicio Wizard of Oz: una experiencia digital simple por delante y una operación manual o semiautomatizada por detrás. Lo importante en esa etapa es comprobar si la coordinación produce un cierre mejor, no simular una escala que todavía no existe.
Una hipótesis B2B2C, no un negocio demostrado
La dirección elegida fue B2B2C. La persona utilizaría el servicio para resolver un problema que ya está afectando su vida; una institución podría financiarlo si obtiene valor operativo suficiente.
El banco podría capturar valor si recibe solicitudes mejor dirigidas, con antecedentes completos y un estado verificable; si reduce contactos repetidos, derivaciones y reconstrucción manual del caso; y si evita que una operación potencialmente viable se pierda solo porque una corrección no llegó a tiempo.
La neutralidad es una condición de confianza. La institución no debería poder modificar el relato de la persona ni convertir la plataforma en una herramienta para negar o dilatar derechos. El producto debe coordinar, registrar y hacer visible el estado, manteniendo claro quién responde cada parte.
La hipótesis económica sigue abierta: licencia base, cobro por volumen, por caso, por usuario o por integración son alternativas posibles. No hay todavía disposición a pagar, costo por caso, baseline de reprocesos ni margen validado. Presentarlo como negocio resuelto sería sobreinterpretar el material.
Lo que sabemos y lo que todavía no sabemos
El discovery produjo una oportunidad más precisa, pero no una validación final. Esa diferencia es parte del caso y no una nota al pie.
- Lo que se sostiene: las anomalías y sus consecuencias son un mejor disparador que el control abstracto de datos; la fragmentación entre actores genera esfuerzo; la certeza del cierre puede ser más valiosa que la visualización permanente.
- Lo que sigue siendo hipótesis: que banca y crédito sean el contexto de mayor urgencia; que el escenario hipotecario ocurra con suficiente frecuencia; que un banco pague por reducir coordinación improductiva; y que la neutralidad sea compatible con la operación real.
- Lo que falta medir: tiempo hasta la resolución, contactos por caso, porcentaje de solicitudes incompletas o mal dirigidas, derivaciones, costo operativo, tasa de reingreso y disposición a pagar.
Esta honestidad cambia la decisión. El siguiente paso no es construir una plataforma completa: es diseñar un experimento que pueda refutar la oportunidad.
Cómo mediríamos si funciona
La métrica principal no debería ser cuántas personas abren la interfaz ni cuántas solicitudes se crean. Debería medir si el problema que originó el caso realmente deja de producir consecuencias.
El piloto debería observar la experiencia de principio a fin:
relato → solicitud correctamente dirigida → respuesta → evidencia → reingreso → continuidad
Para la persona mediríamos comprensión, esfuerzo, confianza y capacidad de retomar la operación. Para el banco, casos completos al primer intento, contactos por caso, tiempo de gestión, reprocesos, derivaciones y operaciones que pudieron continuar. Solo con esa lectura conjunta sería posible hablar de valor económico.
El siguiente experimento
El experimento recomendado es un piloto de seis a ocho semanas con un banco y entre veinte y treinta casos elegibles, si esas condiciones se pueden conseguir. El número no es un resultado ni un compromiso: es un parámetro de diseño para observar suficiente variación sin pretender demostrar escala.
La operación puede comenzar con una persona que recibe el relato, estructura el expediente, coordina con el responsable, actualiza estados y solicita evidencia de cierre. La interfaz muestra lo que ocurriría en un producto futuro, pero el aprendizaje principal proviene de la operación real.
El piloto debe contestar tres puertas antes de hablar de escala:
- Deseabilidad: ¿la persona usa la ruta y la considera mejor que perseguir el caso por su cuenta?
- Efectividad: ¿aumenta la probabilidad de llegar a una Resolución Verificada dentro de la ventana?
- Negocio: ¿el banco reduce trabajo improductivo y reconoce un valor por esa mejora?
Si alguna puerta no se abre, el producto debe recortarse o cambiar de contexto. El objetivo del piloto no es confirmar la idea; es descubrir qué tendría que ser cierto para que valiera la pena construirla.
El aprendizaje
El proyecto comenzó investigando una regulación y terminó identificando un problema de continuidad. La decisión más importante no fue elegir una interfaz, sino cambiar la definición del problema a medida que avanzaba el discovery.
La Ley 21.719 fue una señal para investigar, no una justificación para fabricar una solución. El hallazgo fue que una persona no necesariamente quiere administrar sus datos todo el tiempo: quiere recuperar el control cuando un dato se convierte en una consecuencia importante.
En ese punto, la oportunidad deja de ser “ver mis datos” y pasa a ser demostrar que un problema dejó de afectar aquello que la persona estaba tratando de lograr. Para ella, conseguir su casa. Para el banco, concretar una operación viable con información correcta y menos fricción operativa.
No usamos la Ley 21.719 para justificar una solución. La usamos como señal para investigar si existía algo que realmente valiera la pena construir.
Autor: Cristian Pizarro
Proyecto: Ruta Segura
Contexto: Proyecto desarrollado en el Diplomado de Inteligencia Artificial de la FEN
Equipo: Tamara Valdivia · Valeria Nieto · Erick Fuentealba · Cristian Pizarro
Formato: Opportunity brief y propuesta de validación