# Kulular Teknoloji, corpus en español

## Cómo avanza un proyecto de software, de la oferta a la entrega

Fuente: https://kulular.com.tr/es/publicaciones/como-avanza-un-proyecto-de-software

Una de las primeras preguntas de una organización que quiere encargar un software es cómo será el proceso. Cuándo verán qué, qué se esperará de ellos, cuándo se dará el trabajo por terminado.
En este artículo explico por qué pasos pasa un proyecto, desde la primera reunión hasta el mantenimiento. Los pasos no duran lo mismo en todos los proyectos. En un trabajo pequeño, varios caben en una sola reunión. Pero ninguno se salta, porque el paso que se salta vuelve al final del proyecto en forma de sorpresa.
Primera reunión
En la primera reunión no hablamos de precio. Intentamos entender qué se quiere hacer, cómo funciona hoy el trabajo y qué tiene que cambiar. Quién lo va a usar, qué datos va a tratar, con qué sistemas se va a comunicar.
Al final de esta reunión, a veces decimos que no hace falta software a medida. Si un producto estándar resuelve el trabajo, decirlo desde el principio ahorra tiempo a todos.
Descubrimiento
Si la necesidad no está clara, proponemos una breve fase de descubrimiento. Unos cuantos talleres, un repaso de los sistemas y datos actuales y la descripción paso a paso del proceso de trabajo. El resultado del descubrimiento es un documento escrito: alcance, roles de usuario, integraciones, datos, riesgos conocidos y lo que aún no se sabe.
Es la fase más barata del proyecto y la que más dinero ahorra. Corregir una necesidad mal entendida en un documento es mucho más fácil que corregirla en el código.
Oferta
La oferta se basa en el documento de descubrimiento. Para cada paquete de trabajo consta por escrito qué se hará, cuánto durará, qué se espera de la organización y con qué criterio se aceptará. Lo que queda fuera del alcance también se escribe aparte. Aquí se aclara de quién serán el código fuente y la propiedad intelectual y cómo funcionará el mantenimiento.
Diseño
Antes de escribir código, diseñamos el modelo de datos, la estructura de permisos y las pantallas principales. Enseñamos los bocetos de las pantallas a usuarios reales de la organización. Las objeciones que surgen en esta fase salen mucho más baratas que las que surgen después.
Si se van a tratar datos personales, en esta fase también se decide qué datos se recogen y por qué, quién podrá verlos y cuánto tiempo se conservarán. No son funcionalidades que se añaden después, sino parte de la arquitectura.
Desarrollo
Llevamos el desarrollo en ciclos cortos. Al final de cada ciclo, la organización ve una versión que funciona en el entorno de pruebas. Si algo se ha entendido mal, se nota en unas pocas semanas.
Con cada cambio se ejecutan pruebas automáticas. Si una prueba falla, esa versión no avanza. Explicamos cómo lo hacemos en nuestro propio sitio en otro artículo.
Pruebas y aceptación
La aceptación se hace según los criterios que figuran en la oferta. Para cada funcionalidad, criterios concretos del tipo «en este caso da este resultado». La organización los prueba con sus propios datos, los puntos que no se cumplen se registran y se corrigen.
Cuando los criterios de aceptación no están por escrito, la discusión sobre si «funciona» es inevitable. Explicamos por qué en el artículo que escribimos sobre los criterios de aceptación.
Puesta en producción
La puesta en producción no es un día, sino un pequeño plan. Si hay que migrar datos del sistema antiguo, las migraciones de prueba se hacen antes. Está por escrito cómo volver atrás si algo sale mal. Se da una breve formación a los usuarios y en las primeras semanas se responde rápido a las preguntas.
Mantenimiento
Después de la entrega siguen las actualizaciones de seguridad, las actualizaciones de infraestructura y las pequeñas mejoras. El alcance del mantenimiento y el tiempo en que se atenderá un problema se ponen por escrito en la fase de oferta.
El código fuente, la documentación y los pasos de despliegue se entregan a la organización. Así, si algún día quiere continuar con otro equipo, puede hacerlo.
El papel de la organización
En todos estos pasos hace falta un interlocutor por parte de la organización. Alguien que conozca el proceso de trabajo, que responda pronto a las preguntas y que pueda probar las versiones intermedias. Lo que retrasa los proyectos muchas veces no es un problema técnico, sino la falta de ese interlocutor.
En resumen
Primera reunión, descubrimiento, oferta, diseño, desarrollo, aceptación, puesta en producción y mantenimiento. Los pasos se acortan o se alargan según el tamaño del proyecto, pero ninguno se salta. Que al final de cada paso conste por escrito qué se entrega evita sorpresas al final del proyecto.

## Diez preguntas para elegir una empresa de software

Fuente: https://kulular.com.tr/es/publicaciones/elegir-una-empresa-de-software

Cuando una organización busca una empresa de software, suele tener tres o cuatro ofertas en la mano. Los precios son distintos y los plazos también, pero los textos se parecen mucho. Todos hablan de «metodología ágil», «arquitectura escalable» y «solución integral».
Estas palabras no distinguen a una empresa de otra. Lo que las distingue son las respuestas a las preguntas que se hacen en la primera reunión. En este artículo repaso esas preguntas. Como empresa de software, a nosotros también nos las hacen, y queremos que nos las hagan.
1. ¿Cómo definen el alcance?
Una buena empresa no da un precio en la primera reunión. Primero intenta entender qué hay que hacer. Quién lo va a usar, cómo funciona hoy el trabajo, con qué sistemas tiene que comunicarse, qué datos va a tratar.
Un precio dado sin estas respuestas no es una estimación, es una esperanza. Si la oferta no explica cómo se ha definido el alcance, pregúntelo.
2. ¿Dejan por escrito lo que no saben?
Al principio de todo proyecto hay cosas que no se saben. Cuántos datos vendrán del sistema antiguo, si la documentación de una integración está al día, cómo recibirán los usuarios la nueva pantalla.
Una empresa que lo escribe claramente en la oferta le está enseñando dónde está el riesgo. Una oferta que lo esconde todo dentro de un precio cerrado hace invisible el riesgo. El riesgo no desaparece, solo aparece más tarde.
3. ¿Con qué criterio aceptaremos la entrega?
La mayoría de los desacuerdos en los proyectos de software nacen de la pregunta «¿funciona?». La causa no es técnica. Lo que pasa es que nadie escribió al principio qué significa «funciona».
Haga usted esta pregunta. Para cada funcionalidad debe constar por escrito en qué caso se da por terminada. Lo explicamos en detalle en el artículo que escribimos sobre los criterios de aceptación.
4. ¿Cada cuánto veremos algo que funcione?
No ver durante seis meses un software que se entregará dentro de seis meses es el terreno de los malentendidos más caros. Pida ver una versión en la que se pueda hacer clic, a intervalos regulares. Cada dos semanas o cada mes, pero con regularidad.
5. ¿Quién se queda con el código fuente y la propiedad intelectual?
Esta pregunta debe tener una respuesta clara en el contrato. ¿Se cede el código fuente a la organización o solo se concede un derecho de uso? ¿Qué pasa si la empresa cierra o si se separan los caminos?
Si la respuesta no se escribe, el día que quiera cambiar de empresa puede que solo le quede un programa que funciona.
6. ¿Quién se encargará del mantenimiento después de la entrega?
El software no termina el día de la entrega. Los sistemas operativos se actualizan, aparecen vulnerabilidades en las bibliotecas, los usuarios traen nuevas necesidades. Pregunte por el alcance, la duración y el precio del mantenimiento ya en la fase de oferta. También debe constar por escrito en cuánto tiempo se atenderá un error.
7. ¿Cómo protegen los datos?
Si el software va a tratar datos personales, en la primera reunión ya se ve cómo se acerca la empresa a esos datos. ¿Se registra quién accede a qué datos? ¿Dónde están las copias de seguridad? ¿En qué país están los servidores? ¿Quiénes son los subcontratistas?
Si una empresa responde a estas preguntas con un «no se preocupe», pase a otra que dé respuestas concretas. La seguridad de los datos es una obligación que la ley impone al responsable del tratamiento. Encargar el software a otra empresa no elimina esa obligación.
8. ¿Quién trabajará en el proyecto?
Puede que la persona que viene a la reunión comercial no sea la que escriba el código. Es normal. Pero usted querrá saber quién trabajará en el proyecto, quién tomará las decisiones y quién le responderá. Una empresa que presenta a su equipo con nombre y apellidos responde a esto sin dificultad.
9. ¿Cómo hicieron antes un trabajo parecido?
En lugar de una lista de referencias, pídales que le cuenten un proyecto. Dónde tuvieron dificultades, qué cambiaron, cuál fue el resultado. Una empresa que sabe contar la parte difícil de un proyecto es porque lo ha hecho de verdad.
Puede que no le den el nombre del cliente por confidencialidad. Es normal. Pero deben poder explicar el proceso.
10. ¿Hay algún motivo para que no hagamos este proyecto?
La última pregunta es algo inusual, pero dice mucho. Una buena empresa a veces responde «para esto no hace falta software a medida, este producto estándar le sirve». Otras veces dice «este alcance no cabe en este presupuesto». Oír esto le indica que habla con alguien que dice la verdad aunque pierda el encargo.
Tratamos la decisión entre un paquete estándar y el software a medida en otro artículo.
Cuánto importa estar cerca
Para una organización de Ankara, trabajar con una empresa de software de Ankara es una ventaja, pero no una obligación. Unos cuantos talleres presenciales en las primeras semanas ayudan a entender antes el alcance. Ver juntos un sistema que funciona sobre el terreno, también.
Después, lo decisivo no es la distancia, sino el orden en la comunicación. Que las decisiones queden por escrito, ver versiones con regularidad y recibir respuesta el mismo día sirve más que estar en el mismo edificio.
En resumen
Lo que distingue a una empresa de software no es el precio de la oferta, sino sus respuestas en la primera reunión. Una empresa que responde con datos concretos sobre alcance, criterios de aceptación, código fuente, mantenimiento y seguridad de los datos también trabajará de forma concreta durante el proyecto.

## ¿Paquete estándar o software a medida? Cómo decidir

Fuente: https://kulular.com.tr/es/publicaciones/paquete-o-software-a-medida

Una parte de las organizaciones que acuden a nosotros en realidad no necesita software a medida. Un producto estándar bien configurado les resuelve el trabajo. Para una empresa de software, decir esto significa perder un encargo a corto plazo. A largo plazo, sale mucho más barato que empezar un proyecto equivocado.
En este artículo explico cómo decidimos entre un paquete estándar y el software a medida.
Primera pregunta: ¿hasta qué punto es estándar su trabajo?
Contabilidad, nóminas, correo electrónico, documentos de oficina. Estas tareas funcionan en gran medida igual en todas las organizaciones, y la normativa también hace que se parezcan. En estos ámbitos hay productos maduros y muy extendidos. Desarrollarlos desde cero rara vez tiene sentido.
El proceso que distingue a una organización de las demás es otra cosa. La forma en que un hospital conecta los datos de sus equipos con el flujo clínico, el método de evaluación de un centro educativo, el proceso de producción que una empresa ha desarrollado por su cuenta. Un producto estándar solo encaja en estos procesos si la organización se adapta al producto.
La regla es sencilla. Si su trabajo es estándar, producto estándar. Si lo que le hace distinto está dentro del software, software a medida.
Calcule el coste a cinco años
El primer año de un paquete estándar suele parecer barato. La instalación es rápida y la primera factura, pequeña. Quedarse ahí en la comparación lleva a error.
En un cálculo a cinco años aparecen otras partidas. La licencia, que sube a medida que crece el número de usuarios. Las adaptaciones para las tareas que no encajan en el paquete. Rehacer las adaptaciones que se rompen en la siguiente versión. El segundo proceso informal que se monta para el trabajo que no cabe en el paquete, que muchas veces es una hoja de Excel.
El software a medida también tiene un coste a cinco años. El desarrollo inicial, el alojamiento y el mantenimiento. La diferencia es que ese coste es más previsible y lo controla la organización. Tratamos estas partidas por separado en el artículo que escribimos sobre el coste.
¿Dónde están los datos?
La mayoría de los productos estándar en la nube tienen sus servidores fuera de Turquía. Para una organización que trata datos personales, eso significa, a efectos legales, una transferencia de datos al extranjero. Hay forma de hacerlo, pero la decisión debe tomarse con conocimiento de causa.
También está la cuestión del acceso a los datos. Si quiere dejar el producto estándar, ¿en qué formato, en cuánto tiempo y con qué grado de integridad puede recuperar sus datos? Haga esta pregunta antes de firmar el contrato. Un producto con una respuesta poco clara le ha atado a él.
La dependencia existe en los dos sentidos
Con un paquete estándar, la dependencia es del producto. Usted no decide las subidas de precio, las funciones que se eliminan ni el rumbo del producto.
Con el software a medida también hay dependencia, esta vez de la empresa que lo desarrolla. Si el código fuente no está en sus manos, si no hay documentación y si otro equipo no puede leer el código, cambiar de empresa se vuelve casi imposible. Por eso, con el software a medida hay que exigir que se entreguen a la organización el código fuente, la documentación y los pasos de despliegue.
Muchas veces la respuesta son los dos
Las estructuras más sanas que hemos visto son mixtas. Las tareas estándar funcionan en productos estándar. El proceso que hace distinta a la organización, en software a medida. Y entre ambos hay una integración bien hecha, para que los mismos datos no se introduzcan dos veces.
Con esta estructura, el alcance del software a medida se reduce y se entrega antes. Y los productos estándar se libran de las tareas que les cuestan.
Cuándo decimos que mejor no lo desarrollemos
Cuando una organización acude a nosotros y vemos que su necesidad se cubre con un producto muy extendido, se lo decimos. Si hace falta, le ayudamos a conectar ese producto con sus sistemas actuales. Recomendamos software a medida donde de verdad marca la diferencia.
En resumen
Producto estándar para el trabajo estándar, software a medida para lo que hace distinta a la organización. Haga la comparación con el coste de cinco años, no del primero. Tenga en cuenta también dónde están los datos y cómo los recuperará si se va.

## Qué determina el coste del software a medida

Fuente: https://kulular.com.tr/es/publicaciones/coste-del-software-a-medida

«¿Cuánto costará este software?» es la pregunta que más nos hacen. La respuesta no es una sola cifra, y decirlo parece una evasiva. No lo es. Una cifra dada sin conocer las partidas que determinan el coste es o bien más alta de lo necesario, o bien una cifra que subirá a mitad del proyecto.
En este artículo explico qué partidas determinan el coste de un software a medida y en qué fijarse al leer una oferta. No doy cifras, porque cada proyecto es distinto. Pero ver de dónde sale la cifra hace mucho más fácil comparar ofertas.
El número de pantallas es una medida engañosa
El coste del software suele pensarse en número de pantallas. Una pantalla de inicio de sesión, un listado, un formulario, un informe. Pero las pantallas son la parte visible del coste.
Dos formularios que parecen iguales pueden tener costes muy distintos. Uno escribe los datos introducidos en una tabla. El otro valida esos mismos datos, los muestra a personas distintas según sus permisos, los envía a otro sistema y registra cada cambio. El coste lo determinan las reglas que hay detrás de la pantalla.
Integraciones
Un software rara vez funciona solo. El sistema de contabilidad, la autenticación, los pagos, el correo electrónico, los sistemas antiguos de la organización o un servicio público. Cada conexión es un trabajo aparte.
Conectarse a un servicio bien documentado y con una interfaz sólida puede llevar unos días. Conectarse a un sistema antiguo con documentación incompleta y sin entorno de pruebas puede llevar semanas. Preguntar en la fase de oferta por la documentación y las posibilidades de prueba de cada integración aclara la parte más incierta del coste.
Datos y migración
Si el nuevo software no empieza con una base de datos vacía, habrá que migrar datos del sistema antiguo. En la mayoría de las ofertas esto ocupa una sola línea, y es uno de los puntos donde más a menudo se retrasan los proyectos. Explicamos por qué en el artículo que escribimos sobre la migración de datos.
Seguridad y normativa
Un software que trata datos de salud, datos de estudiantes o datos financieros requiere más trabajo que una herramienta interna de aspecto similar. Acceso basado en roles, registros de acceso, cifrado, aplicación de plazos de conservación, supresión y anonimización. Son tareas difíciles de añadir después. Incluirlas en el alcance desde el principio es más barato y más seguro.
Incertidumbre
En todo proyecto hay cosas que no se saben. Una buena oferta las escribe por separado y dice cómo se tratarán. Una mala oferta, en cambio, o suma la incertidumbre al precio en silencio o no la tiene en cuenta. Lo segundo es más peligroso, porque la diferencia aparece a mitad del proyecto en forma de factura adicional.
La mejor forma de reducir la incertidumbre es poner una breve fase de descubrimiento al principio del proyecto. En esa fase se aclaran el alcance, las integraciones y los datos. Después, el desarrollo propiamente dicho se presupuesta con una cifra más sólida.
Pruebas y aceptación
Las pruebas son la partida más expuesta a recortes. Cuando se recortan, también son la partida que se paga más tarde. Pruebas automáticas, pruebas de aceptación y pruebas con usuarios reales. Si en la oferta no se ve el esfuerzo dedicado a las pruebas, ese esfuerzo o no se hará o recaerá sobre su equipo.
Después de la entrega
El coste del software no termina el día de la entrega. Siguen el alojamiento, las copias de seguridad, las actualizaciones de seguridad, la actualización de las bibliotecas que se usan y las pequeñas mejoras. Ver estas partidas por separado en la fase de oferta evita sorpresas al final del primer año.
Al leer una oferta
Cuando compare varias ofertas, escriba una al lado de otra qué incluye cada una. Si están incluidas las integraciones, si está incluida la migración de datos, cuánto hay de pruebas, cómo se presupuesta el mantenimiento, de quién será el código fuente. La mayoría de las diferencias de precio muestran que no se está presupuestando el mismo trabajo.
En resumen
El coste del software a medida no lo determinan las pantallas, sino las reglas que hay detrás de ellas, las integraciones, los datos, la seguridad, las pruebas y el mantenimiento. Una oferta que escribe claramente estas partidas, aunque parezca más cara, muchas veces sale más barata.

## Cómo crear una web corporativa: notas de nuestro propio sitio

Fuente: https://kulular.com.tr/es/publicaciones/como-construimos-este-sitio

El sitio web de una empresa de software es el primer software que escribe esa empresa. Quien lo abre no ve el código, pero ve el resultado. Si la página tarda en cargar, si en otro idioma se ha quedado una frase en turco, si el formulario de contacto deja de funcionar sin avisar, lo atribuye al trabajo de la empresa.
Por eso no construimos el sitio como un folleto, sino como un pequeño producto. A continuación explico qué decisiones tomamos, por qué y en qué nos equivocamos.
Generación estática
El sitio está escrito con Next.js. En la primera versión, las páginas se volvían a generar en el servidor con cada petición. La causa era una línea inocente: el layout raíz leía la cabecera de la petición para averiguar el idioma. Next considera dinámica cualquier página en la que ve esto.
El resultado fue que Cloudflare no podía guardar ninguna página en caché. Cada visita llegaba hasta el servidor de Hetzner. Al medirlo en local, el tiempo hasta el primer byte era de unos pocos milisegundos. Es decir, el código no era lento. El problema aparecería con la escala.
La solución fue deducir el idioma de la dirección y no de la petición. Cada idioma tiene su propio layout raíz, y el idioma se sabe por la carpeta en la que está la página. Hoy las casi trescientas páginas se generan todas una sola vez durante la compilación.
Siete idiomas y coherencia
El sitio se publica en turco, inglés, francés, portugués, alemán, español y árabe. La traducción en sí es la parte fácil. Lo difícil es que, cuando cambia un texto, cambie en siete sitios a la vez.
La mayoría de los errores que encontramos en las primeras revisiones salían del mismo patrón. Una larga cadena de condiciones que elegía el texto según el idioma caía en silencio en la última rama cuando se olvidaba de un idioma. Y la última rama solía ser la turca. Así aparecía una frase en turco en mitad de una página en francés.
Lo resolvimos con una función auxiliar. Cada lugar que elige un texto está obligado a dar los siete idiomas a la vez. Si falta un idioma, el código no compila. El error se detecta antes de publicarse.
El título académico era un problema parecido. En una traducción, el título «Doç. Dr.» se había convertido en profesor. Ahora el título no se traduce en ningún idioma. Se toma del registro en turco, y una prueba lo comprueba en cada push.
Pruebas
No montamos un marco de pruebas pesado. Escribimos nueve pruebas con el módulo de pruebas propio de Node. Cada una detecta un error que ya nos ocurrió de verdad.
Entre ellas están que el título sea el mismo en todos los idiomas, que ningún texto contenga una raya, que el nombre de la marca no se traduzca, que cada artículo en turco tenga su equivalente en los otros seis idiomas y que los textos legales no se resuman al traducirlos. La última prueba es tosca, pero funciona: si la página legal en un idioma tiene menos del sesenta por ciento de la extensión de la turca, lo más probable es que se haya resumido.
En cada push a GitHub se ejecutan la comprobación de tipos, el lint, estas pruebas y la compilación de producción. Si una falla, la versión no se publica.
Seguridad
La política de seguridad de contenidos es estricta. No se pueden cargar scripts, fuentes ni imágenes desde un dominio externo. Las fuentes vienen de nuestro propio servidor, así que el navegador del visitante no envía peticiones a terceros al abrir la página. Google Analytics solo se carga si el visitante da su consentimiento.
La pantalla del protocolo de trabajo de la página de inicio envía a un modelo de lenguaje el texto que escribe el visitante. Es el punto del sitio más fácil de usar de forma abusiva. Alguien que quiera usar gratis un modelo de pago podría llamar directamente al endpoint. Lo impedimos con varias capas: la comprobación de que la petición viene de nuestra página, un ticket firmado de corta duración y de un solo uso, un límite por hora y por día para cada dirección, un techo diario para todo el sitio y un límite al número de peticiones que pueden ir al modelo a la vez.
Despliegue
El código está en GitHub. En el servidor de Hetzner funciona Coolify, que con cada push a la rama principal vuelve a compilar el sitio como imagen de Docker y lo publica. Un despliegue tarda unos dos minutos y medio.
Delante está Cloudflare. Al pasar a la generación estática, también el HTML se pudo guardar en caché, y las páginas se mantienen allí hasta una hora.
En qué nos equivocamos
La caché fue tanto la fuente de la velocidad como la de un malentendido. Publicamos una nueva versión, Coolify dijo que todo había ido bien, pero la página de inicio seguía saliendo como antes. La causa era sencilla. Cloudflare no pedía la nueva copia hasta que caducaba la que tenía.
La solución correcta es vaciar la caché automáticamente al final de cada despliegue. El proceso de publicación no termina cuando termina en el servidor, sino cuando termina donde lo ve el visitante.
También está la accesibilidad. El análisis automático no encontraba errores en las páginas. Pero las pequeñas etiquetas de la página de inicio estaban sobre una fotografía semitransparente, y la herramienta de análisis no puede medir el contraste sobre una fotografía. Medimos aparte los píxeles que había detrás de las etiquetas, y la relación rondaba 3:1. Al aclarar un poco la fotografía y oscurecer un tono las etiquetas, superó 5:1. Hay que mirar incluso cuando la herramienta dice «sin errores».
Por qué lo contamos
Decirle a un cliente «entregamos software que funciona» es fácil. Al explicar con claridad lo que hicimos en este sitio, también resulta fácil ver en qué se apoya esa frase.

## Un agente de IA que responde correos: cómo marcamos los límites de KAI

Fuente: https://kulular.com.tr/es/publicaciones/los-limites-de-kai

KAI es el miembro de inteligencia artificial de nuestro equipo. Aparece con su nombre en la página del equipo, porque no queríamos esconder el uso de la inteligencia artificial en segundo plano. Pero ponerle nombre a una inteligencia artificial es la parte fácil. La verdadera pregunta es cuánto trabajo le deja usted.
Hoy KAI lee los correos que llegan a la empresa. Los rutinarios los responde por sí mismo y organiza reuniones. En los que no son rutinarios solo prepara un borrador, y la decisión de enviarlo o no la toma alguien del equipo. Este artículo explica dónde trazamos esa línea y por qué.
Las dos opciones fáciles eran erróneas
Hay dos opciones que se le ocurren a uno primero. La primera es que el agente lo envíe todo por sí mismo. La segunda es que una persona apruebe cada respuesta antes de enviarla.
La primera es claramente arriesgada. Un modelo de lenguaje puede inventarse un precio o una fecha de entrega con total seguridad. La otra parte lo lee como un compromiso de la empresa.
La segunda parece segura, pero en la práctica no funciona. Ya lo explicamos en otro artículo sobre la gobernanza de la inteligencia artificial. En un sistema que pide aprobación para cada respuesta, al cabo de un tiempo la tasa de aprobación se acerca al cien por cien. La persona que aprueba deja de leer el texto. Sobre el papel hay supervisión humana. En la realidad decide el sistema.
Con qué criterio trazamos la línea
Para considerar rutinario un correo nos hicimos dos preguntas. ¿Se conoce la respuesta de antemano? Si fuera errónea, ¿se podría corregir con facilidad?
Si respondemos que sí a las dos, la tarea es rutinaria. Proponer una hora para una reunión, confirmar la recepción de un documento o responder a una pregunta general con la información del sitio entran en esta categoría. Si KAI propone una hora equivocada, la otra parte la corrige en el siguiente mensaje y nadie sale perjudicado.
Si respondemos que no aunque sea a una, la tarea no es rutinaria. Toda conversación que incluya precios, alcance, contratos, fechas de entrega o datos personales está en esta categoría. Aquí KAI prepara un borrador, pero el mensaje no sale sin la decisión de alguien del equipo.
La ventaja de esta distinción es que mantiene la aprobación humana escasa pero significativa. Cada mensaje que requiere aprobación exige pensar de verdad. Quien aprueba sabe que lo que tiene delante es importante.
Indicar en la firma que es una inteligencia artificial
En la firma de cada correo que envía KAI se indica que el mensaje lo ha escrito un sistema de inteligencia artificial. Lo hacemos por dos motivos.
El primero es la honestidad. La otra parte no debe creer que escribe a una persona y confiar en consecuencia. El segundo es la normativa. El Reglamento (UE) 2024/1689 de Inteligencia Artificial exige que las personas sepan que están interactuando con una inteligencia artificial. Para nuestros interlocutores en Europa es una obligación. Para los de Turquía, también es un buen hábito.
Lo que no puede hacer
KAI no tiene poder de firma en la empresa. No puede hacer ofertas, no puede cerrar contratos y no puede interpretar la normativa. Estos límites no están solo en una lista de reglas. También están trazados en las herramientas que el agente puede usar. Si usted no le da un permiso a un agente, tampoco necesita confiar en que no lo usará.
KAI accede a un modelo de lenguaje a través de OpenRouter. Esto significa que las conversaciones van a un proveedor de servicios en el extranjero. Lo explicamos aparte en nuestro aviso informativo. Allí también pedimos que no se envíe por correo información confidencial, datos personales de categoría especial ni secretos comerciales.
Dónde se pone a prueba este diseño
La línea entre lo rutinario y lo no rutinario no siempre es nítida. «No puedo ir a la reunión, ¿podría ser otro día?» es un mensaje rutinario. «No puedo ir a la reunión porque vamos a suspender el proyecto» no lo es. Los dos empiezan con la misma frase.
Por eso, en caso de duda, el comportamiento por defecto es preparar un borrador. KAI no considera rutinario un mensaje del que no está seguro. Equivocarse en esa dirección, es decir, dejarle trabajo innecesario a una persona, sale más barato que equivocarse en la contraria.
Qué trasladamos a los proyectos de clientes
El criterio que usamos en nuestro propio trabajo se traslada también a los sistemas que montamos para los clientes. No activamos ni desactivamos la autonomía de un agente con un solo interruptor. Clasificamos las tareas según si la respuesta se conoce de antemano y si el error se puede deshacer. Según su categoría, el agente termina la tarea o deja un borrador.
Este criterio no es perfecto. Pero podemos escribir con claridad dónde se sitúa, y un límite que podemos escribir es un límite que podemos auditar.

## Migrar datos a un nuevo software: por qué contamos los registros tres veces

Fuente: https://kulular.com.tr/es/publicaciones/migrar-datos-de-sistemas-antiguos

Cuando una organización pasa a un sistema nuevo, de lo que más se habla es de sus funciones. Las pantallas, los informes, la aplicación móvil. Cómo se van a trasladar los datos del sistema antiguo suele quedar para el final, y se despacha con un «ya haremos una transferencia».
Ahí es donde los proyectos se atascan de verdad. El código funciona, las pantallas están listas, pero parte de los registros de clientes llega incompleta y nadie sabe cuántos faltan ni por qué.
En este artículo cuento qué comprobamos antes, durante y después de la migración.
Primero, el inventario
La migración no empieza con la primera línea de código, sino con una lista. Qué tablas hay en el sistema antiguo, cuántos registros tiene cada una, qué significa cada campo y cuál ya no se usa.
La sorpresa más frecuente en esta lista es que la misma información se guarda en dos sitios. La dirección del cliente está tanto en la tabla de clientes como en la de facturas, y las dos no coinciden. Cuál se da por correcta no es una decisión técnica, sino una que debe tomar la organización. Hay que preguntarlo antes de migrar.
La segunda sorpresa es que el sistema antiguo sea un archivo de Excel. En Excel, todo campo que no está sujeto a una regla es un campo en el que algún día alguien escribió otra cosa «de forma provisional». Aparecen filas con «no hay» en la columna de fecha y celdas con dos números en la columna de teléfono.
Mapeo de campos
Dos sistemas no guardan los datos de la misma forma. El sistema antiguo puede tener un único campo de «nombre y apellidos» y el nuevo, dos campos separados. La ciudad, que en el antiguo era texto libre, puede elegirse de una lista en el nuevo.
Para cada campo escribimos una regla de mapeo: campo antiguo, campo nuevo y la conversión entre ambos. Los registros que no cumplen la regla no se corrigen en silencio. Van a una lista aparte. Esa lista la revisamos uno por uno junto con la organización.
La corrección silenciosa parece tentadora, pero es lo peor que se puede hacer en una migración. Un registro erróneo ya lo era en el sistema antiguo. Si durante la migración se corrige a ojo, en el nuevo sistema queda un registro que parece correcto pero no lo es. Nadie volverá a darse cuenta.
Contar tres veces
Para decir «terminado» cuando acaba la migración, contamos los registros en tres puntos.
El primero es el origen. El número de registros que deben migrarse en el sistema antiguo, tabla por tabla.
El segundo es la transferencia. El número de registros que el script de migración lee, convierte y aparta en la lista separada.
El tercero es el destino. El número de registros que se crean de verdad en el nuevo sistema.
El origen debe ser igual a la suma de los transferidos y los apartados. Y los transferidos deben ser iguales al destino. Si estas dos igualdades no se cumplen, la migración no ha terminado, por pequeña que sea la diferencia. Una diferencia de unos cientos de registros significa que se ha perdido el historial de unos cientos de clientes.
Que cuadren los números no basta por sí solo. Los números pueden cuadrar y el contenido estar dañado. Por eso abrimos registros elegidos al azar en los dos sistemas, uno al lado del otro, y los comparamos campo por campo. Para los campos críticos, como importes y fechas, calculamos además totales y valores resumen en los dos lados.
Migración de prueba y plan de vuelta atrás
No hacemos la migración real por primera vez el día real. Antes hacemos al menos dos migraciones de prueba con una copia de los datos. En cada prueba medimos el tiempo, revisamos los registros apartados y corregimos las reglas de mapeo.
Antes de la migración real, el plan de vuelta atrás queda por escrito. Qué se hará si la migración se queda a medias o si los números no cuadran, hasta qué punto se podrá volver al sistema antiguo y quién tomará esa decisión. Cuando estas preguntas se hacen el día de la migración, las respuestas se dan con prisas.
Los dos sistemas a la vez durante un breve periodo
Siempre que es posible, después de poner en marcha el nuevo sistema, el antiguo sigue abierto en modo de solo lectura durante un breve periodo. Si un registro parece incompleto o erróneo, se puede consultar el sistema antiguo y compararlos.
El final de este periodo se fija desde el principio. Si no se fija, los dos sistemas conviven durante meses y se vuelve a discutir cuál de ellos es el correcto.
No migrar también es una decisión
No todos los registros antiguos tienen que pasar al nuevo sistema. Trasladar al nuevo sistema los datos cuyo plazo de conservación ha vencido obliga a la organización a seguir guardándolos sin necesidad. En el caso de los datos personales, esto puede convertirse además en un incumplimiento de una obligación.
La migración es un buen momento para hacer esta depuración. Identificamos los registros cuyo plazo de conservación ha vencido, los dejamos fuera de la migración con la aprobación de la organización y dejamos constancia del borrado. Así el nuevo sistema empieza limpio.
En resumen
La migración de datos no es una transferencia, sino un pequeño proyecto. Una migración hecha sin inventario, mapeo, recuento en tres fases, migración de prueba y plan de vuelta atrás hace perder la confianza en el nuevo sistema desde su primer día.

## Cuándo no funciona la supervisión humana en un sistema de IA

Fuente: https://kulular.com.tr/es/publicaciones/supervision-de-ia

Al desarrollar un sistema de IA para organizaciones, una de las primeras cosas que se piden es la aprobación humana. Este artículo explica cómo saber si esa aprobación funciona de verdad dentro del sistema.
Cuando se habla de gobernanza de la inteligencia artificial, la frase que más se oye es esta. "Hay aprobación humana, la decisión no queda en manos de la máquina."
Cuando oigo esa frase, solo hago una pregunta. ¿Cuál es su tasa de aprobación?
No llega respuesta, porque no se mide. En los pocos lugares donde sí se mide, el resultado suele superar el noventa y ocho por ciento. Es decir, la persona supervisora rechaza el modelo una vez de cada cincuenta decisiones. Decir que en ese cuadro existe supervisión humana es formalmente cierto pero funcionalmente falso. Quien decide de hecho es el sistema; la persona solo firma.
Por qué el botón de aprobación no funciona
La causa no es la mala fe, sino el diseño.
Si a un usuario se le muestran trescientas recomendaciones al día y se le pide que apruebe cada una, ese usuario se automatiza en poco tiempo. Si la tasa de acierto del modelo es alta, esto se acelera aún más, porque también en los pocos casos que rechaza el modelo suele tener razón, y el usuario deja de confiar en su propio juicio.
Esto se llama en la literatura confianza excesiva en la automatización, y es un fenómeno bien conocido. Es decir, cuanto mejor funciona el sistema, más se debilita la supervisión humana. Es un hecho que hay que tener en cuenta al diseñar la supervisión.
Las tres condiciones que hacen significativa la supervisión
Para que la supervisión sea funcional, deben darse tres cosas a la vez.
La persona supervisora debe poder ver el fundamento de la recomendación. Si no se muestra a partir de qué entradas llegó el modelo a ese resultado, la persona solo puede evaluar el resultado, y para evaluarlo tendría que decidir todo de nuevo por su cuenta. Esto hace la supervisión prácticamente imposible.
Rechazar debe ser gratuito. Un usuario al que rechazar le exige rellenar un formulario adicional, redactar una justificación y obtener la aprobación de su superior, opta por no rechazar. El flujo de rechazo debe ser al menos tan sencillo como el de aprobación.
El rechazo debe tener una consecuencia. Si las recomendaciones rechazadas se anotan en algún sitio y nadie las mira, la persona supervisora lo nota y con el tiempo pierde interés. Que los casos rechazados alimenten la mejora del modelo mantiene viva la supervisión.
No existe supervisión que no se mida
Incluso una vez cumplidas estas tres condiciones, sigue haciendo falta medir.
Hay al menos tres indicadores que deben vigilarse. La tasa de rechazo, el tiempo medio dedicado por decisión y la tasa de acierto posterior de las decisiones rechazadas. Si el tiempo por decisión ha bajado al orden de los segundos, no se está supervisando. Si la tasa de rechazo se acerca a cero, la conclusión es la misma.
Muy pocas organizaciones tienen respuesta cuando se les preguntan estos indicadores en una auditoría. Sin embargo, no son mediciones difíciles: se extraen de datos que el propio sistema ya genera.
El derecho a impugnar determina la arquitectura
El artículo 11 de la Ley 6698 reconoce a la persona el derecho a impugnar un resultado adverso derivado exclusivamente del análisis por sistemas automatizados.
La consecuencia técnica de esta disposición es directa. Cuando llega una impugnación, hay que poder mostrar cómo se tomó la decisión. Si no se puede mostrar, no se puede defender la decisión.
De ahí se deriva esta regla arquitectónica. En un flujo que produce consecuencias para una persona no puede usarse un modelo que no genere una justificación. Esto debe escribirse desde el principio como una restricción en la selección del modelo. Añadir explicabilidad a posteriori no es posible en la mayoría de las arquitecturas.
Llevar registro no basta, hay que registrar lo correcto
Al hablar de pista de auditoría, lo primero que viene a la mente es llevar un registro, pero lo determinante es el contenido de ese registro.
Para que una decisión pueda revisarse después, deben registrarse conjuntamente cinco elementos. Los datos que entraron en el sistema, la versión del modelo, el resultado producido, la justificación en que se basa ese resultado y la decisión final tomada por la persona. Si estos cinco se guardan en sistemas separados, después no pueden emparejarse. Si no se registró la versión del modelo, meses después no hay forma de responder a la pregunta de qué decía el modelo en esa fecha.
La versión del modelo sin registrar es, en la práctica, la carencia que veo con más frecuencia. El modelo se actualiza, se intenta explicar decisiones antiguas con el modelo nuevo, y no cuadra.
Hay que mostrar la diferencia entre certeza e incertidumbre
Un último punto. El sistema debe mostrar de forma distinguible el resultado que produce con baja confianza frente al que produce con alta confianza.
Si esa distinción no existe, el usuario confía por igual en todos ellos y no recibe ninguna advertencia justo donde el error es más probable. Sin embargo, la incertidumbre del propio modelo suele poder medirse. Llevar esa medición a la interfaz es la mejora más barata y más eficaz de la supervisión.
Si tuviera que elegir una sola cosa que hacer hoy en un proyecto de inteligencia artificial, esa sería mi elección.

## La cláusula que más se olvida en un proyecto de software: los criterios de aceptación

Fuente: https://kulular.com.tr/es/publicaciones/contratos-de-desarrollo-de-software

Como empresa de software, es uno de los primeros temas que tratamos en cada proyecto. Un proyecto que empieza sin criterios de aceptación escritos es un proyecto en el que, hasta el día de la entrega, cada uno espera algo distinto.
Cuando se abre un expediente de litigio de software, las partes suelen discutir esto. Si el software funciona o no.
La razón por la que este debate no se resuelve no es técnica. En el contrato no consta qué significa "funciona". Si no hay criterio de aceptación, el desarrollador dice que entregó, el cliente dice que no lo recibió, y ambos tienen razón según su propio criterio.
Esta única carencia es el denominador común de los litigios de software que he visto.
Cómo debe redactarse el criterio de aceptación
La aceptación es el momento que produce la consecuencia jurídica de la entrega. También desde ahí empieza a correr el plazo de responsabilidad por vicios. Es decir, que esa fecha sea incierta significa que también es incierto cuándo termina la responsabilidad.
Una cláusula de aceptación que funciona incluye lo siguiente. La lista de pruebas de aceptación, el entorno en que se ejecutará la prueba, quién la ejecutará, el plazo de objeción y la regla de que, si no llega objeción dentro del plazo, la aceptación se tendrá por producida.
El elemento que más se omite es el entorno de prueba. Un software que funciona en la máquina del desarrollador puede no funcionar en el entorno del cliente, y en ese punto se discute quién es responsable. Si el entorno está definido en el contrato, esa discusión no surge.
Vincular el criterio de aceptación a la satisfacción subjetiva es, por su parte, la peor opción. Una aceptación condicionada "a la satisfacción del cliente" crea una obligación sin límite temporal, y el trabajo del desarrollador nunca termina.
Los derechos de propiedad intelectual no pasan automáticamente
El segundo error frecuente es la presunción de propiedad. El cliente cree que, a cambio del precio pagado, es propietario del código. Jurídicamente, la situación no es esa.
Los programas de ordenador están protegidos como obra bajo la Ley n.º 5846, y, salvo pacto en contrario, los derechos patrimoniales permanecen en el titular de la obra. La cesión debe regularse expresamente, hacerse por escrito, y los derechos cedidos deben enumerarse uno por uno. Una fórmula general como "se ceden todos los derechos" queda abierta a discusión.
Además, hay que distinguir tres categorías. El código escrito específicamente para el cliente suele cederse. Los componentes preexistentes del desarrollador no se ceden, se licencian, y el alcance y la duración de la licencia se redactan por separado. Los componentes de código abierto están sujetos a sus propias licencias, y la lista de los utilizados debe adjuntarse como anexo al contrato.
Cuando estas tres categorías no se distinguen, ocurre lo siguiente. El cliente cree que es propietario de todo el código, el desarrollador sigue usando su propia biblioteca en otro proyecto, y el problema solo se advierte cuando surge un litigio.
Un contrato sin gestión de cambios no funciona
Por bien redactado que esté el pliego de alcance, durante el proyecto llegan solicitudes de cambio. Si el contrato no dice cómo se tramitará esa solicitud, cada petición se convierte en una negociación.
Una regulación que funciona responde a estas preguntas. A quién y de qué forma se comunica la solicitud. Quién hace el análisis de impacto y en cuántos días. Cómo se calcula el efecto sobre el precio y el calendario. Con la firma de quién se da la aprobación. Qué ocurre con la solicitud no aprobada.
Cuando estas cinco preguntas tienen respuesta, el cambio deja de ser una crisis y se convierte en un proceso.
La condición de encargado del tratamiento surge sin que se note
Si el desarrollador accede a datos personales del cliente, pasa a tener la condición de encargado del tratamiento en el sentido de la Ley 6698. Esta condición se adquiere muchas veces sin que nadie se dé cuenta.
El caso más frecuente es el uso de datos reales en el entorno de pruebas. Se lleva una copia de la base de datos de producción al entorno de pruebas, los desarrolladores trabajan con ella, y desde ese momento nace una relación de tratamiento de datos. Si el contrato no contiene disposición al respecto, esa relación funciona sin fundamento jurídico.
La solución más limpia es no dejar que esta situación llegue a producirse. Probar con datos enmascarados o sintéticos no es técnicamente difícil y elimina en gran medida el riesgo. Si el acceso a datos reales es realmente indispensable, deben regularse por escrito el objeto, la duración y la finalidad del tratamiento, la sujeción del desarrollador a instrucciones, el uso de subencargados, las medidas de seguridad, y la devolución o destrucción de los datos al final del contrato.
El mantenimiento es un contrato aparte
Por último, el mantenimiento y el soporte. Esta es una prestación distinta del desarrollo y debe regularse por separado.
Lo que hay que escribir no es el tiempo de intervención, sino la clasificación de incidencias. Si no se define qué incidencia entra en qué categoría, cada incidencia se reclama con la máxima prioridad. Una vez definidas las categorías, el tiempo de intervención y de resolución se escribe por separado para cada una.
Además está la cuestión de la medición. Un compromiso de nivel de servicio que no sea medible queda sin sanción cuando se incumple. Cómo se hará esa medición y según el registro de quién debe constar en el contrato.
Quién debe redactar el contrato
Todas estas cláusulas exigen que el derecho y la ingeniería decidan juntos. El abogado no puede redactar el criterio de aceptación por sí solo, porque no sabe qué es comprobable. El ingeniero no puede redactar por sí solo la cesión de derechos de propiedad intelectual.
La parte que acude a la negociación del contrato sin equipo técnico acaba aceptando cláusulas que después resultan inaplicables. La cláusula inaplicable, cuando surge el litigio, se comporta como si nunca hubiera existido.

## Un servicio en la nube en el extranjero también es una transferencia de datos

Fuente: https://kulular.com.tr/es/publicaciones/transferencias-internacionales-de-datos

Al elegir la infraestructura de un software, dónde está el servidor suele discutirse en términos de precio y velocidad. Esta elección también tiene una parte de transferencia de datos, y no es fácil cambiarla después.
Si se pregunta a una organización si transfiere datos al extranjero, la respuesta suele ser que no. Si a continuación se pregunta qué servicios utiliza, aparece una lista: alojamiento en la nube, correo electrónico, software de atención al cliente, una herramienta de análisis, un proveedor de pagos, un servicio de copias de seguridad.
La mayoría de los servicios de esa lista no tienen sus servidores en Türkiye. Es decir, la respuesta real era sí, y la organización no lo sabía.
Este malentendido viene de la propia palabra "transferencia", que sugiere un acto deliberado: coger un archivo y enviarlo. Pero mantener datos en un sistema en el extranjero, o hacer que se procesen allí, también es una transferencia. No hace falta buscar un acto de envío por separado.
Ver dónde empieza realmente una transferencia
El artículo 9 de la Ley turca 6698 regula las transferencias al extranjero. La dificultad en la práctica no está en la norma en sí, sino en determinar cuándo se ha producido realmente una transferencia.
Las tres situaciones siguientes dan lugar a una transferencia: que los datos estén alojados en un servidor en el extranjero; que un equipo en el extranjero pueda acceder al sistema con fines de soporte; y que los datos se procesen en el extranjero y el resultado se devuelva. La tercera es la que más se pasa por alto. Si utiliza un servicio de análisis de texto y ese servicio está en el extranjero, el texto que envía se procesa allí. Que le devuelvan el resultado no significa que no haya habido transferencia.
Nuestro propio sitio tiene exactamente esta característica. El campo de texto libre de la página de inicio envía el texto introducido a un proveedor en el extranjero para su análisis. Por eso nuestro aviso de protección de datos dedica un apartado a esto, y un visitante puede recorrer el resto del sitio entero sin usar nunca ese campo. Que no se produzca ninguna transferencia cuando la función no se usa fue una decisión de diseño tanto como la propia función.
La columna que falta en el inventario
La mayoría de los inventarios de datos recogen la categoría, la finalidad y el plazo de conservación. La columna que falta es esta: ¿en qué país se encuentran físicamente estos datos?
Al añadir esa columna, el panorama cambia. Parte de los datos que la organización creía guardar en su propio centro de datos resultan estar en el extranjero. Las copias de seguridad son lo que más se pasa por alto, porque el servicio de copias de seguridad suele contratarse a un proveedor aparte y nadie comprueba dónde está.
Al elaborar el inventario hay que preguntar directamente al proveedor. Si el contrato incluye un compromiso sobre la residencia de los datos, hay que obtenerlo por escrito. Si no lo incluye, el proveedor puede cambiar esa disposición unilateralmente sin que usted se entere.
La cadena de subencargados
La segunda capa es aún menos visible. El proveedor que usted utiliza puede depender a su vez de otros proveedores para su propia infraestructura.
Usa un programa de atención al cliente; ese programa funciona sobre un proveedor de nube; ese proveedor usa otro servicio distinto para la búsqueda; y se conecta a un tercero para enviar notificaciones. Sus datos circulan por toda esa cadena.
No es posible controlar esa cadena por completo, pero sí hacerla visible. El contrato debe exigir que se notifique el uso de subencargados y dar derecho a oponerse a un cambio. La mayoría de los proveedores empresariales ya ofrecen esto, solo hay que pedirlo.
Qué hacer
El primer paso es elaborar un inventario de servicios: el nombre de cada servicio externo utilizado, para qué se usa, a qué categorías de datos personales puede acceder y dónde están sus servidores.
Una vez hecha esa tabla, hay tres opciones: sustituir el servicio por una alternativa alojada en Türkiye, trasladarlo a la región turca del proveedor si la tiene, o dar a la transferencia una base jurídica adecuada mediante uno de los mecanismos que prevé la ley.
Las tres tienen un coste, y la elección correcta depende de la naturaleza del trabajo. Pero no elegir ninguna, es decir, no haberse dado cuenta de la situación, es la opción más cara, porque además significa que su aviso de protección de datos está dando información inexacta, y una sola omisión acaba incumpliendo dos obligaciones a la vez.
La normativa en esta materia sigue evolucionando, y las resoluciones del Consejo redibujan el marco de vez en cuando. Conviene revisar la situación actual antes de elegir un mecanismo de transferencia.

## 72 horas ante una brecha de datos: a dónde se va el tiempo en el lado del software

Fuente: https://kulular.com.tr/es/publicaciones/notificacion-de-brechas-de-datos

La notificación de una brecha se presenta como un proceso jurídico. Pero cuánto de ese plazo se pierde lo determina cómo se diseñó el sistema meses antes del incidente.
Una alerta llega a la mesa de una organización un lunes por la mañana: se ha detectado un acceso inusual en un servidor. A partir de ese momento, el reloj de las setenta y dos horas empieza a correr.
Setenta y dos horas suena a mucho tiempo. Lo que sigue es un relato hora a hora de adónde va realmente ese tiempo, porque sin ver ese desglose es difícil entender por qué la preparación frente a una brecha tiene que hacerse meses antes, no durante ella.
Las primeras ocho horas: ¿es esto realmente una brecha?
La primera tarea es determinar si la alerta es real. Puede ser un falso positivo, una operación de mantenimiento o un permiso mal configurado.
En esta fase, el equipo técnico revisa los registros. Si los registros no son lo bastante buenos, y en la mayoría de las organizaciones no lo son, esto se alarga. Sin saber qué cuenta accedió a qué tabla desde qué dirección, no se puede dar ningún paso posterior.
El primer punto crítico es este. Si no lleva registros, el reloj empieza a agotarse aquí, y ese tiempo no se recupera nunca.
Las siguientes veinticuatro horas: qué datos se vieron afectados
Una vez establecido que se trata de una brecha, surge una sola pregunta. ¿Qué datos personales había en ese servidor?
Una organización con un inventario actualizado responde a esto en diez minutos. Una que no lo tiene intenta averiguarlo examinando el esquema de la base de datos, comprobando nombres de tablas, extrayendo registros de muestra, preguntando a los desarrolladores. Solo eso puede llevar fácilmente un día entero.
La segunda mitad de la pregunta es más difícil. ¿Qué hay en las copias de seguridad? ¿Existe una copia que se exportó para un informe? ¿Se cargó una muestra en un entorno de pruebas? Si las respuestas no están escritas en ningún sitio, acaban basándose en suposiciones, y una notificación basada en suposiciones termina teniendo que corregirse después.
Las siguientes doce horas: a cuántas personas afecta
Una vez delimitado el alcance, hay que producir una cifra. Cuántos interesados, qué categorías de datos, qué zonas geográficas.
Un error frecuente aquí es redondear la cifra. Decir "aproximadamente diez mil personas" no hará que se rechace la notificación, pero que más tarde aparezca una cifra real bien distinta daña la credibilidad de lo declarado por la organización. Si no se puede obtener una cifra precisa, es mejor decirlo así, y explicar por qué, que aventurar una.
El tiempo restante: preparar y enviar la notificación
La notificación al Consejo debe cubrir cuándo y cómo ocurrió la brecha, qué categorías de datos se vieron afectadas, sus posibles consecuencias y las medidas adoptadas y previstas.
Redactar eso partiendo de una página en blanco consume el tiempo que quede. Una organización con una plantilla ya lista la rellena en media hora. Quién está autorizado a firmarla también debe decidirse de antemano, porque si esa discusión empieza en esta fase, no hay tiempo para ella.
Notificar a las personas afectadas es una tarea aparte. Se hace tan pronto como sea razonablemente posible una vez identificadas las personas afectadas; si el contacto directo no es posible, se recurre a otro medio adecuado. El lenguaje importa aquí. Un mensaje enterrado en detalle técnico impide que la persona entienda lo que realmente tiene que hacer.
Lo que el plan tiene que contener de verdad
La lección de este recorrido es esta. El valor de un plan de respuesta a incidentes está en haber pensado de antemano lo que hay que pensar en el momento del incidente.
Necesita un reparto claro de funciones. Quién delimita el incidente, quién decide que es una brecha, quién firma. Un plan que depende de una sola persona se hunde el día que esa persona está de baja.
Necesita un umbral definido. Qué se considera brecha debe estar escrito de antemano; de lo contrario, esa discusión ocurre dentro de las setenta y dos horas.
Necesita una regla de preservación de pruebas. El primer instinto suele ser limpiar los sistemas afectados, lo que hace imposible una investigación adecuada. El plan debe decir explícitamente que los registros se conservan intactos.
Necesita plantillas de comunicación ya preparadas, tanto para el Consejo como para los interesados afectados.
Nada termina cuando se envía la notificación
La notificación no es el fin de la obligación. El Consejo evalúa si las medidas técnicas y organizativas adoptadas fueron suficientes.
Una brecha que se repite en la misma organización se interpreta como prueba de que esas medidas no eran suficientes. Por eso la acción correctiva adoptada tras una brecha debe quedar registrada y su efecto debe medirse. La frase "se han tomado las medidas necesarias" no es, por sí sola, prueba de nada.
Lo único que merece la pena hacer hoy
Lo más rentable que puede hacer antes de sufrir una brecha es elaborar el inventario junto con la ubicación física de los datos: qué base de datos, qué tabla, qué campo y qué copia de seguridad contiene cada dato.
Si esa tabla existe, aproximadamente las primeras treinta de las setenta y dos horas quedan recuperadas de hecho. Si no existe, por bien redactado que esté el plan, el tiempo no alcanzará.

## Por qué la cláusula informativa debe coincidir con el esquema de la base de datos

Fuente: https://kulular.com.tr/es/publicaciones/redactar-un-aviso-de-privacidad

Este artículo empieza con un texto jurídico, pero el origen del problema está en el software. El lugar que muestra con más exactitud qué datos recoge una organización es el esquema de la base de datos de la aplicación que usa. Si la cláusula informativa no coincide con ese esquema, la corrección muchas veces no debe empezar por el texto, sino por el sistema.
Cuando reviso el aviso de protección de datos de una organización, lo primero que hago no es leerlo. Es coger las categorías de datos que enumera y compararlas con el esquema de la base de datos.
Esa comparación arroja casi siempre el mismo resultado: hay campos que el aviso no menciona. A veces ocurre lo contrario, categorías que el aviso enumera pero que el sistema nunca llega a recoger. Ambos casos apuntan al mismo problema de fondo. El aviso se elaboró a partir de una plantilla, no de una comprobación real de los hechos.
El deber no es redactar un documento
El artículo 10 de la Ley 6698 exige que el responsable del tratamiento, al recabar datos personales, comunique ciertas cosas: su identidad, la finalidad del tratamiento, los destinatarios a los que se transferirán los datos y por qué, el método de recogida y la base jurídica, además de los derechos recogidos en el artículo 11.
El verbo clave aquí es comunicar. El documento es un vehículo; el deber consiste en dar información exacta. Un aviso que da información inexacta es peor que no tener aviso alguno, porque la organización ha hecho ya una declaración que no coincide con la realidad.
Por eso redactar el aviso tiene que venir después del inventario, no antes. Una organización con inventario escribe el aviso en un día. Una que no lo tiene lo escribe sin saber realmente sobre qué está escribiendo.
Los cinco errores que veo con más frecuencia
Llevo años viendo los mismos errores, y ninguno de ellos se debe a falta de conocimiento jurídico.
Fundir el aviso y el consentimiento expreso en una sola casilla. El usuario marca "he leído y acepto" y se le considera a la vez informado y consintiente. El aviso es una comunicación, no algo que se acepta. Esa fusión debilita el carácter del consentimiento como declaración de voluntad independiente.
Mostrar el aviso después de que la operación ya se ha completado. Se envía el formulario y luego aparece un enlace al aviso en una página de agradecimiento. Para entonces los datos ya se han recogido.
Forzar un único aviso a cubrir todos los procesos. Selección de personal, contacto con clientes, relación con proveedores y visitas al sitio web se agrupan en un mismo documento. El resultado es un aviso general que no describe con exactitud ninguno de ellos.
No indicar la base jurídica, o enumerarlas todas a la vez. Una frase como "conforme a las condiciones previstas en los artículos 5 y 6" no indica base jurídica alguna. Debe escribirse aquella de la que dependa realmente cada tratamiento concreto.
No indicar el plazo de conservación. El Comunicado espera que esto figure en la información dada al interesado, y si no se indica, el interesado no tiene manera de saber durante cuánto tiempo se conservarán sus datos.
Cómo debe estructurarse el aviso
Un buen aviso se redacta proceso por proceso. No empieza con "nuestra empresa trata sus datos personales", empieza con "cuando rellena el formulario de contacto, se tratan los siguientes datos".
Elaborar una tabla de cuatro columnas para cada proceso facilita mucho acertar: categoría de datos, finalidad del tratamiento, base jurídica, plazo de conservación. Con esa tabla lista, el aviso prácticamente se escribe solo, y quien lo lee puede encontrar lo que busca.
El lenguaje también importa. El Comunicado exige que la información se transmita con un lenguaje claro, comprensible y sencillo. En la práctica vemos lo contrario. Los avisos se alargan, las frases se vuelven pesadas y el resultado deja de leerse. Un aviso que nadie lee no cumple su función de comunicación. Simplificarlo no es aquí una cuestión de estilo, es lo que exige el deber.
Mantener el aviso al día
Un aviso de protección de datos no es un documento que se escribe una vez y se olvida. Cuando se añade un nuevo campo, se empieza a trabajar con un nuevo proveedor o se incorpora una nueva transferencia, el aviso también debe actualizarse.
La única manera sostenible de lograrlo es vincular la actualización al propio proceso de desarrollo. Un cambio que añade un nuevo campo de datos personales al modelo de datos debe activar también la actualización del inventario y del aviso. Sin ese vínculo, el aviso se aleja de la realidad ya en el primer año, y nadie se da cuenta.
Así construimos ese vínculo en nuestro propio sitio. Cuando añadimos la función de análisis asistido por inteligencia artificial, entró al mismo tiempo en el aviso una sección aparte que explica la transferencia internacional. La función no se publicó sin ella. Ese debe ser el orden.

## Software conforme a la KVKK: empezar por el inventario de datos

Fuente: https://kulular.com.tr/es/publicaciones/cumplimiento-de-la-kvkk

Las organizaciones suelen acudir a nosotros diciendo que quieren un software conforme a la KVKK. Para ver dónde empieza esa conformidad en el código, primero hay que mirar el inventario, porque sin saber qué datos se guardan y dónde no se puede definir bien ni una regla de acceso ni un plazo de conservación.
Cuando se acude a una organización para un trabajo de cumplimiento de la KVKK, suele encontrarse lo siguiente. Un aviso de privacidad, un formulario de consentimiento expreso, una política de conservación y destrucción. Los tres están preparados, firmados y archivados.
Después se hace una sola pregunta. ¿De dónde salieron las categorías de datos que figuran en estos textos?
La respuesta suele ser esta. Se tomó un modelo encontrado en internet, se escribió el nombre de la organización, se añadieron algunos puntos. Es decir, la declaración no se derivó de la comprobación de la realidad, sino de una plantilla. Este es el error de orden más frecuente y más costoso que he visto en los trabajos de cumplimiento.
Por qué el orden importa tanto
El aviso de privacidad es una declaración. El artículo 10 de la Ley exige que el responsable del tratamiento comunique las categorías de datos tratados, las finalidades, los destinatarios a los que se transferirán y la base jurídica. Si se hace una declaración, esa declaración tiene que ser exacta.
Un texto escrito sin elaborar el inventario no puede ser exacto. En el mejor de los casos, será incompleto. Cuando en una auditoría se detecta una actividad de tratamiento que no figura en el texto, no se trata solo de una carencia técnica, sino de un incumplimiento del deber de informar de manera adecuada.
Lo contrario también es cierto. Una organización que ya dispone del inventario redacta el aviso de privacidad en un día, porque todo lo que hay que escribir ya está determinado.
Qué se busca realmente en el inventario
La tabla de inventario suele elaborarse con las columnas de categoría de datos, finalidad y plazo de conservación. Estas tres columnas no bastan.
La columna que falta es esta. ¿Dónde está físicamente este dato? ¿En qué base de datos, en qué tabla, en qué campo? ¿Existe también en las copias de seguridad? ¿Existe una copia en el sistema de un proveedor externo?
Cuando esta pregunta no se hace, el inventario refleja la opinión que la organización tiene de sí misma, no la realidad. Cuando se produce una violación de datos, la primera pregunta será "qué datos personales había en ese servidor". Un inventario que no indica la ubicación física resulta inútil en ese momento.
La elección de la base jurídica es una decisión arquitectónica
El artículo 5 de la Ley enumera las condiciones de tratamiento. En la práctica, este artículo suele tratarse como una formalidad, cuando en realidad la base jurídica elegida determina directamente cómo debe construirse el sistema.
En una actividad de tratamiento basada en el consentimiento expreso, el consentimiento puede retirarse en cualquier momento. En el instante en que se retira, el tratamiento debe cesar. Esto exige tres cosas en el sistema. Un registro de a qué versión del texto se dio el consentimiento, una interfaz que ofrezca al usuario la posibilidad de retirarlo, y un control que detenga el tratamiento correspondiente cuando el consentimiento se retira. Si falta alguna de las tres, basarse en el consentimiento coloca a la organización en una posición indefendible.
En cambio, un tratamiento necesario para la ejecución de un contrato no requiere estos mecanismos. El mismo dato, tratado con una base jurídica distinta, genera una carga técnica completamente diferente. Por eso la elección de la base jurídica no debe hacerla el abogado en solitario, al margen de la arquitectura.
El plazo de conservación y el componente que lo aplica
Fijar un plazo de conservación es la parte más fácil del trabajo de cumplimiento. Conseguir que se aplique es la más difícil.
Un diseño que funciona tiene este aspecto. Cada registro lleva su propio plazo de conservación, por ejemplo un campo fin_conservacion. Un proceso que recorre periódicamente los registros cuyo plazo ha vencido. Ese proceso borra, destruye o anonimiza el registro y anota la operación realizada en una tabla aparte. Lo que se presenta en una auditoría no es el texto de la política, sino esa tabla.
Las organizaciones que no construyen esta estructura suelen hacer lo siguiente. Escriben el plazo en la política, dejan la aplicación para una fecha posterior, y esa fecha nunca llega. Pasados dos años, se encuentran con datos no eliminados y con un documento que dice que deberían haberse eliminado. Que ambas cosas coexistan es peor que no haber escrito ninguna política.
VERBİS y la cuestión del alcance
La obligación de inscribirse en el Registro de Responsables del Tratamiento está sujeta a criterios fijados por el Consejo. El número anual de empleados, el volumen del balance financiero y la naturaleza de los datos tratados son determinantes.
Aquí hace falta una advertencia. El alcance de la exención ha cambiado con el tiempo mediante decisiones del Consejo y puede seguir cambiando. Una organización exenta hoy puede quedar obligada cuando aumente su número de empleados. Por eso la exención no es algo que se determine una sola vez y se olvide, debe comprobarse anualmente. Para los umbrales actuales hay que consultar los comunicados publicados por la Autoridad.
El plan de violación se redacta de antemano
El párrafo quinto del artículo 12 de la Ley exige que la violación se notifique al Consejo lo antes posible. Las decisiones del Consejo han concretado ese plazo en setenta y dos horas.
Setenta y dos horas es el tiempo total asignado, tras detectar el incidente, para determinar su alcance, identificar a las personas afectadas y preparar la notificación. Incluso el primero de estos pasos lleva días en la mayoría de las organizaciones, porque no está por escrito dónde se guarda cada dato.
Es decir, la preparación frente a una violación empieza mucho antes de que ocurra, y desemboca de nuevo en lo mismo. El inventario.
Qué ocurre cuando el cumplimiento termina
No termina. Una nueva funcionalidad genera un nuevo campo de datos. Un nuevo proveedor genera una nueva transferencia. Las decisiones del Consejo estrechan el marco.
Por eso hay que dejar de concebir el cumplimiento como un proyecto y encajarlo dentro del propio proceso de desarrollo del producto. Si actualizar el inventario al añadir un nuevo campo pasa a formar parte de la revisión de código, el proceso se sostiene a sí mismo. De lo contrario, cada año se empieza de cero y se repite el mismo error de orden.

## El software de tecnología jurídica necesita algo más que generar documentos

Fuente: https://kulular.com.tr/es/publicaciones/tecnologias-juridicas

La tecnología jurídica es uno de los cinco ámbitos en los que desarrollamos software. El error que más vemos en este ámbito es buscar el valor del producto en el documento que genera. El valor real está en que la regla funcione dentro del sistema siempre de la misma forma.
Cuando se observa la presentación de un producto de tecnología jurídica, lo más probable es que se vea lo siguiente. Genera borradores de contratos, propone cláusulas, da formato al documento. Son tareas útiles. El problema es que la verdadera cuestión del ámbito no es esta, y el problema que creemos que resuelven estas herramientas es, en realidad, la parte más fácil del problema.
La verdadera cuestión está aquí. Una organización está sujeta a una obligación jurídica. Se hace una interpretación sobre lo que significa esa obligación. La interpretación se escribe en un documento. Después ese documento se archiva, y el funcionamiento diario de la organización continúa sin conocer ese documento. Esta desconexión entre el documento y el sistema es el error más costoso que veo en la práctica, y ninguna herramienta de plantillas de contratos lo resuelve.
Interpretar es cosa de personas, aplicar es cosa del sistema
Convertir una regla en software no es escribir la regla en código. Entre ambas cosas hay un paso que no puede automatizarse.
El artículo 7 de la Ley 6698 establece que, cuando desaparezcan las razones que exigían su tratamiento, el dato personal se borrará, destruirá o anonimizará. Esta disposición es clara. Pero ¿qué significa exactamente "que desaparezca la razón" respecto a los datos de facturación de una organización? ¿El fin de la relación con el cliente, el vencimiento del plazo de conservación previsto en la normativa fiscal, o lo que ocurra más tarde de las dos cosas? A esta pregunta responde un jurista. Su respuesta es una interpretación, y mientras esa interpretación no quede registrada, dentro de seis meses nadie recordará por qué se eligió ese plazo.
Ahí empieza el trabajo del software. Una vez dada la interpretación, asegurar que se aplique siempre de la misma manera y que pueda demostrarse que se ha aplicado. Si dispone de un sistema que hace esto, está usando tecnología jurídica. Si solo genera plantillas, está usando un procesador de texto.
Qué ocurre cuando el documento y el sistema se separan
Veámoslo con un ejemplo concreto. En la política de conservación de una organización consta que los registros de comunicación con clientes se conservarán durante dos años. Cuando llega una auditoría, se presenta esa política.
El auditor hace una única pregunta. ¿Qué componente aplica este plazo?
La respuesta, la mayoría de las veces, no existe. En la base de datos hay un campo created_at, pero no hay expires_at. No existe ningún proceso que elimine el registro cuando el plazo vence. Aunque exista una eliminación, no genera ningún registro de lo actuado. Al final, la organización no puede demostrar que hace lo que su política dice. La política en sí misma no es una prueba, es a lo sumo una declaración de intenciones.
La forma de corregir este panorama no es redactar un mejor texto de política. Es añadir al modelo de datos un campo que transporte el plazo de conservación, escribir un componente que aplique ese plazo, y hacer que ese componente genere un registro cuando se ejecute. Cuando las tres cosas están presentes, el texto de la política deja de ser una afirmación y pasa a ser la descripción de lo que el sistema realmente hace.
Los cinco eslabones de la cadena
Convertir un texto jurídico en un control que funciona dentro del sistema ocurre en cinco pasos. El orden de estos pasos importa, y omitir cualquiera de ellos hace que el resultado deje de ser fiable.
Primero se identifica la norma. Se determina la regla aplicable y, si existe, su excepción. Después se hace la interpretación, es decir, se decide qué significa la regla en el proceso de negocio concreto. Este paso corresponde a una persona y debe quedar registrado. En el tercer paso, la interpretación se vincula a la arquitectura, determinando qué campo transportará qué regla. En el cuarto paso se escribe el componente que aplica la regla en el momento de la operación. En el quinto paso se registra que ese componente se ha ejecutado.
Un control escrito sin haber hecho la interpretación aplica la regla equivocada. Un control que no produce evidencia no sirve en una auditoría. El error que veo con frecuencia es que se salten el tercer y el cuarto paso y se pase directamente al quinto. La organización lleva un registro, anota algo allí, pero no queda claro qué regla demuestra que se ha aplicado.
La cuestión del monopolio de la abogacía
Existe un límite que toda persona que desarrolle productos en este ámbito debe conocer. El artículo 35 de la Ley de la Abogacía n.º 1136 reserva a los abogados la tramitación de asuntos jurídicos y la emisión de dictámenes jurídicos.
En la práctica, esto determina qué puede y qué no puede decir su producto. Decir "en su contrato falta esta cláusula" es informar. Decir "no firme este contrato, tendrá consecuencias en su contra" es emitir una opinión. La línea entre ambas es fina y debe protegerse de forma consciente en el diseño del producto. El método más sólido para mantener esa línea es que el sistema no tome la decisión por sí mismo y que detrás de cada resultado siga siendo visible una decisión humana.
Este límite parece un obstáculo, pero en realidad es una buena restricción de diseño. Un sistema que no asume la decisión tampoco asume la responsabilidad cuando comete un error, y esto impide que el usuario confíe ciegamente en el sistema.
Qué ha cambiado la inteligencia artificial y qué no
El procesamiento del lenguaje natural aporta una ganancia real de eficiencia en el análisis de documentos. Encontrar un tipo determinado de cláusula entre cientos de contratos era antes una tarea de semanas. Ahora se hace en horas.
Lo que no cambia es la responsabilidad. Si no se puede rastrear de qué documento y de qué párrafo procede el resultado producido por el modelo, ese resultado no es una constatación, es una conjetura. Del mismo modo, si el sistema no muestra de forma distinguible un resultado del que no está seguro frente a uno del que sí lo está, el usuario confía igual en todos ellos, y el error pasa desapercibido.
Cuando estas dos condiciones no se cumplen, la ganancia de eficiencia obtenida se compensa después con el riesgo que surge. Y lo peor es que no se sabe cuándo se materializará ese riesgo.
Por dónde empezar
Al iniciar un proyecto corporativo de tecnología jurídica, recomiendo elegir una única obligación. Abordarlas todas a la vez suena bien, pero en la práctica ninguna llega a completarse.
Para la obligación elegida se construyen los cinco eslabones completos. Se redacta la norma, la interpretación queda registrada, se vincula al modelo de datos, el control funciona, se produce la evidencia. Este trabajo se completa en seis semanas, y al final no tendrá un informe, sino un control que funciona y un registro que puede mostrarse en una auditoría.
La segunda obligación avanza mucho más rápido. Porque lo difícil no es la regla, es construir la cadena por primera vez.

## La responsabilidad del Estado en las empresas emergentes de tecnología espacial

Fuente: https://kulular.com.tr/es/publicaciones/derecho-espacial

Para los equipos que tratan datos de satélite o desarrollan software para empresas espaciales, esta norma parece lejana. Sin embargo, influye en muchas decisiones, desde cómo se guardarán los datos hasta cómo se estructurará el contrato.
En el derecho espacial existe una única regla que funciona de manera distinta a la de cualquier otra rama del derecho, y la mayoría de los emprendedores la descubre tarde.
El artículo 6 del Tratado del Espacio Ultraterrestre de 1967 establece que los Estados son internacionalmente responsables de las actividades espaciales nacionales. El resultado no cambia aunque la actividad la lleve a cabo una empresa privada. El artículo añade además que esas actividades quedan sujetas a la autorización y a la supervisión continua del Estado correspondiente.
Es más fácil entender lo que esto significa con un ejemplo. Cuando una empresa de software comete un error, responde ante su cliente. Cuando una empresa espacial comete un error, es el Estado quien pasa a responder ante otro Estado. La diferencia no es de escala, es de naturaleza.
Cómo se construye la cadena de responsabilidad
El Convenio sobre Responsabilidad de 1972 concreta esta cadena. Por los daños causados en la superficie de la Tierra o a una aeronave en vuelo, el Estado de lanzamiento tiene responsabilidad objetiva. Es decir, no se exige culpa.
Esto produce una consecuencia directa en el plano comercial. El Estado querrá trasladar al operador privado esta responsabilidad que puede recaer sobre él. Por eso el documento de autorización suele contener cláusulas de repetición, obligación de seguro y requisitos de garantía. Si al empezar a negociar el contrato no conoce el importe de estas partidas, tampoco conoce el coste real del proyecto.
El registro está ligado a esto. El Convenio sobre Registro de 1975 exige la inscripción de los objetos lanzados al espacio. El registro determina bajo la jurisdicción y el control de qué Estado se encuentra un objeto. Es decir, aquí empieza la respuesta a la pregunta de qué derecho resulta aplicable.
El mapa de autorización en Turquía
La Agencia Espacial Turca se creó en 2018 mediante Decreto Presidencial y es responsable de elaborar el programa espacial nacional y de coordinar las actividades.
Pero la actividad espacial no queda limitada a un único organismo. El uso de frecuencias y órbitas está sujeto a un régimen aparte, en el que resultan determinantes las regulaciones de la Unión Internacional de Telecomunicaciones. A nivel nacional, la autoridad competente es el organismo turco de tecnologías de la información y las comunicaciones. Si está en juego el control de exportaciones, entran en juego otras autoridades.
Al iniciar un proyecto hay que elaborar este mapa. Qué permiso se obtiene de qué organismo, en qué orden y en cuánto tiempo. Este calendario avanza de forma independiente del calendario de desarrollo técnico y suele ser más largo que él. Lo que retrasa el proyecto muchas veces no es el software, es el permiso.
Los propios datos son una cuestión aparte
El problema práctico que con más frecuencia me encuentro en los proyectos espaciales no es técnico, tiene que ver con los datos.
Los derechos sobre los datos de la misión deben regularse en los contratos de lanzamiento y de operación. Si queda un vacío en el contrato, resolverlo después es muy difícil, porque la contraparte ya ha tenido acceso a esos datos y una limitación retroactiva no funciona en la práctica.
Los datos de observación de la Tierra plantean una cuestión aparte. A medida que aumenta la resolución, se refuerza la probabilidad de que el dato adquiera el carácter de dato personal. Una imagen en la que puede leerse la matrícula de un vehículo no está sujeta al mismo régimen que una imagen a escala de una ciudad. Al diseñar el sistema hay que determinar a partir de qué resolución entra en juego un régimen de tratamiento distinto, y esto debe construirse como un punto de control en la propia línea de datos.
El tercer punto es la integridad. Debe poder demostrarse el origen del dato de telemetría, su marca de tiempo y que no ha sido alterado. Es lo único que tendrá valor probatorio cuando se realice un examen posterior a un incidente. Si existe la posibilidad de que el registro se haya generado a posteriori, el registro en sí mismo no sirve como defensa.
El debate sobre la extracción de recursos
El artículo 2 del Tratado prohíbe la apropiación nacional. La situación de la extracción de recursos de los cuerpos celestes frente a esta prohibición no es clara.
Algunos Estados han adoptado en su legislación interna normas que reconocen la propiedad sobre el recurso extraído. La compatibilidad de estas normas con el Tratado es discutida, y todavía no se ha consolidado una práctica internacional asentada en la materia. Lo honesto que puede decirse a una iniciativa que trabaje en este ámbito es lo siguiente. El terreno jurídico no está asentado, y esa incertidumbre debe anotarse como una partida de riesgo en la decisión de inversión. Cualquier opinión que se presente como definitiva ofrece hoy por hoy una información incompleta.
Qué llevar a la mesa de negociación del contrato
En los proyectos espaciales veo el mismo problema allí donde el equipo técnico y el equipo jurídico trabajan por separado. Las decisiones tomadas al escribir el software del segmento terrestre afectan directamente al régimen de responsabilidad, y esta conexión suele advertirse recién después de firmado el contrato.
A la primera negociación deben llegarse con estos tres puntos ya definidos. De qué organismo y con qué condiciones se obtendrá la autorización. Cómo se repartirá entre las partes la responsabilidad y la carga del seguro. A quién pertenecerán los derechos sobre los datos de la misión y quién podrá acceder a ellos. La planificación técnica que se hace sin haber resuelto estos tres puntos acaba teniendo que rehacerse después.

## Cuándo se considera producto sanitario un software de salud

Fuente: https://kulular.com.tr/es/publicaciones/derecho-sanitario

Para un equipo que desarrolla software de salud, la respuesta a esta pregunta cambia el plazo y el coste del proyecto. El mismo código puede llevar una carga de cumplimiento muy distinta según cómo se defina el producto.
Imagine dos aplicaciones. Ambas toman los síntomas introducidos por el usuario, ejecutan un algoritmo y devuelven una lista. El código es casi idéntico. Una está sujeta a la normativa sobre productos sanitarios, la otra no.
Lo que marca la diferencia es el texto descriptivo en la tienda de aplicaciones. La primera dice "informa sobre posibles afecciones según sus síntomas". La segunda dice "evalúa sus síntomas y muestra el diagnóstico probable". Esta segunda frase convierte el producto en uno presentado con fines de diagnóstico, y con ello entran en juego la clasificación de riesgo, la evaluación de la conformidad, el expediente técnico, la evaluación clínica y las obligaciones de vigilancia poscomercialización.
Este es el error más caro y más fácilmente evitable que he visto en proyectos de tecnología sanitaria. La descripción del producto la redacta el equipo de marketing, nadie piensa en su consecuencia jurídica, y el producto entra en un régimen de conformidad que nunca se pretendió asumir.
La finalidad de uso es un texto jurídico
La regla práctica que se deriva de esto es la siguiente. La descripción del producto debe redactarse con el mismo cuidado que una política de privacidad, y pasar por una revisión jurídica antes de publicarse.
Esa revisión no debe limitarse a la descripción de la tienda. El titular en el sitio web, la frase del vídeo promocional, la afirmación en la presentación comercial y el texto del documento de soporte pueden producir el mismo resultado. Si en un sitio ha dicho "diagnostica", decir en otro "es solo informativo" no retira esa declaración.
Hay que tomar la decisión desde el principio. Si el producto va a ser un producto sanitario, el proceso que exige ese régimen se establece desde el inicio y entra en el plan como una partida de coste. Si no va a serlo, mantener ese límite en cada texto debe convertirse en una regla de desarrollo del producto.
La arquitectura de acceso a los datos de salud
El artículo 6 de la Ley 6698 considera los datos de salud una categoría especial de datos personales y somete su tratamiento a condiciones más restringidas. La traducción técnica de esta calificación queda incompleta en la mayoría de los proyectos.
El panorama que veo con frecuencia es este. La aplicación funciona, los datos se guardan, pero en el sistema todo el mundo puede ver todo. El desarrollador puede consultar la base de datos de producción, el equipo de soporte puede abrir el historial del paciente, la persona directiva puede ver datos en bruto en los informes. Esto significa que el acceso no está limitado, y es difícil de defender en una auditoría.
El diseño correcto empieza por el control de acceso basado en roles, pero no termina ahí. Cada acceso debe quedar registrado, ese registro debe mostrar quién lo hizo y con qué finalidad, y un acceso fuera de lo habitual debe poder detectarse. Si alguien abre el historial de un paciente a medianoche, eso tiene que ser visible en el sistema.
El entorno de pruebas es una cuestión aparte. Probar con datos reales de pacientes es el hábito más común y más arriesgado en la tecnología sanitaria. Trabajar con datos enmascarados o sintéticos elimina en gran medida ese riesgo y no es técnicamente difícil de implementar.
Apoyo clínico a la decisión y responsabilidad
Los sistemas de apoyo a la decisión con inteligencia artificial plantean la pregunta de quién es responsable. En la práctica, la configuración segura es que el sistema genere la recomendación y la decisión final quede en manos del profesional sanitario competente.
Para que esta configuración no quede solo sobre el papel, deben conservarse conjuntamente tres registros. La recomendación producida por el sistema, los datos en que se basa esa recomendación, y la decisión final tomada por el profesional sanitario. Si los tres se guardan por separado, no podrán cruzarse después; si no se guardan en absoluto, no podrá demostrarse dónde recae la responsabilidad.
Conviene añadir aquí un indicador. Debe vigilarse la tasa con la que el profesional sanitario rechaza la recomendación del sistema. Si esa tasa se acerca a cero, la supervisión humana se ha vuelto formal, y en ese punto es de hecho el sistema quien toma la decisión. Esta constatación puede ser determinante en un debate sobre responsabilidad.
Los servicios de salud a distancia
Los servicios de salud a distancia se rigen por la normativa del Ministerio de Salud. Qué servicios pueden prestarse a distancia, las obligaciones de registro y los límites del servicio se determinan en normativa secundaria. Como esta normativa puede cambiar con el tiempo, al diseñar el producto hay que consultar el texto vigente.
El principio que no cambia es este. Las situaciones que requieren una exploración presencial no pueden atenderse a distancia. Una aplicación de salud a distancia debe poder reconocer y redirigir una solicitud que exceda ese límite. Que el sistema pueda decir "para esta situación, acuda por favor a un médico" no es una característica de usabilidad, es un requisito jurídico.
Al empezar un proyecto
En los proyectos de tecnología sanitaria, la pregunta que hay que responder en la primera reunión no es qué hará el producto, sino qué va a declarar que es. Cada línea de código escrita sin haber respondido a esta pregunta puede haberse escrito conforme al régimen equivocado.
La segunda pregunta corresponde al modelo de datos. Qué dato es realmente necesario, quién podrá verlo, dónde se registrará el acceso y qué ocurrirá cuando la finalidad haya terminado. La respuesta a estas cuatro preguntas determina directamente el diseño de las tablas, y cambiarlo después, al exigir migrar datos de pacientes ya existentes, genera un problema tanto técnico como jurídico.

## Cámara obligatoria y proporcionalidad en el software de exámenes en línea

Fuente: https://kulular.com.tr/es/publicaciones/derecho-educativo

Para un equipo que desarrolla software de exámenes en línea, esta pregunta parece una elección técnica. Si se enciende la cámara, si se guarda la grabación. En realidad es una decisión de diseño que determina qué datos tratará el producto, y cambiarla después sale caro.
Un alumno se niega a encender la cámara en un examen a distancia y explica que no quiere que se grabe su casa. La institución responde que hay que garantizar la integridad del examen. En este punto chocan dos intereses legítimos, y la cuestión no es cuál de los dos tiene razón, sino si el método elegido por la institución es realmente necesario.
Esta pregunta se me plantea constantemente en proyectos de tecnología educativa, y suele debatirse en un marco equivocado. El debate se convierte en el dilema de "¿se enciende la cámara o no?", cuando la pregunta que jurídicamente hay que hacer es más estrecha. ¿Puede alcanzarse el mismo fin tratando menos datos?
Qué pregunta la proporcionalidad
El artículo 4 de la Ley 6698 exige que los datos personales sean pertinentes, limitados y proporcionados en relación con los fines para los que se tratan. Este principio no es un buen deseo abstracto, sino una herramienta de filtrado concreta.
La integridad del examen es un fin legítimo, en eso no hay discusión. Pero ese fin no legitima cualquier dato que pueda recogerse sobre el candidato. Grabación de vídeo continua, captura de pantalla, seguimiento de los movimientos del teclado y del ratón, instalación de un cliente que exige amplios permisos en el dispositivo. Cada uno de estos elementos debe evaluarse por separado, y para cada uno hay que preguntarse: ¿no puede garantizarse la integridad del examen sin esto?
En la mayoría de los casos, sí puede garantizarse. Aleatorizar el banco de preguntas, fijar un límite de tiempo, mezclar el orden de las preguntas, aumentar el peso de las preguntas abiertas y un análisis estadístico posterior de anomalías consiguen un nivel serio de integridad sin necesidad de grabar. Pasar directamente a la grabación por cámara sin probar antes estas herramientas es una elección difícil de defender en términos de proporcionalidad.
Por qué el consentimiento no funciona aquí
El primer reflejo de las instituciones es pedir el consentimiento del alumno. Antes de empezar el examen aparece una casilla de aceptación, y el alumno no puede entrar al examen si no la marca.
El problema de este planteamiento es el siguiente. Para que el consentimiento sea válido, debe haberse dado con voluntad libre. Es difícil sostener que el consentimiento de un alumno que, de no aceptar, no puede presentarse al examen, se apoya en una voluntad libre. Y además, del otro lado está la institución que pone la nota, registra la asistencia y afecta a la decisión de graduación. Ese desequilibrio de poder vicia el consentimiento desde el principio.
La conclusión práctica que se deriva de esto es la siguiente. Basarse en el consentimiento para los datos del alumnado da a la institución una sensación de seguridad, pero no ofrece protección jurídica. Lo que la institución debe hacer es evaluar si el tratamiento se apoya en otra base jurídica y, si no es así, renunciar a ese tratamiento.
Cuando está en juego un menor
Respecto a los alumnos en edad de escolarización obligatoria, el panorama es aún más delicado. Aquí, la capacidad para consentir, el papel de los padres o tutores y el interés superior del menor son cuestiones que deben valorarse por separado.
Al diseñar una plataforma educativa, hay que establecer flujos distintos según la edad del usuario. Ofrecer la misma interfaz tanto a un alumno de diez años como a un estudiante de máster de veinticinco es problemático no solo en términos de usabilidad, sino también jurídicamente. Un campo en el modelo de datos que registre el grupo de edad, con reglas de tratamiento distintas asociadas a ese campo, es la traducción técnica de esa distinción.
Qué demuestra el registro de aprendizaje
El aspecto menos comentado de la tecnología educativa es para qué sirve después el registro que produce.
Cuando un alumno impugna una calificación, ¿qué tiene la institución en sus manos? ¿Un simple registro de "examen completado", como quien cierra un billete, o una cadena que muestre qué respuesta se dio a cada pregunta, con qué criterio se puntuó y quién la evaluó?
Si existe lo segundo, la reclamación se resuelve en diez minutos. Si no, la reclamación se convierte en una defensa que pide confiar en el propio registro de la institución, y esa defensa es débil. Por eso, al diseñar un sistema de evaluación debe seguirse este orden. Primero se redacta el resultado de aprendizaje. Después el criterio de aprobación se vincula a ese resultado. La pregunta se genera según el criterio. Se conserva el registro de la evaluación. La vía de reclamación y el procedimiento de revisión se definen de antemano.
Cuando esta cadena está construida, el certificado de aprobación tiene detrás un fundamento demostrable. Cuando no lo está, el certificado queda reducido a una declaración que depende de la buena fe de la institución.
Mi recomendación a las instituciones
Antes de comprar software de vigilancia, midan qué parte del problema de integridad puede resolverse con el propio diseño del examen. En la mayoría de las instituciones esta medición nunca se hace, y se pasa directamente a la solución más intrusiva.
Si tras esa medición sigue siendo necesaria la vigilancia, redacten una justificación separada para cada dato que se recoja. "El sistema lo recoge" no es una justificación. El dato cuya justificación no pueda escribirse debe eliminarse del sistema. Esto debe ser también objeto del contrato con el proveedor, porque la mayoría de los productos listos para usar recogen más de lo necesario y vienen con esos ajustes por defecto.

## Por qué un producto de software no está sujeto a una sola ley

Fuente: https://kulular.com.tr/es/publicaciones/derecho-digital

Como equipo que desarrolla software, esta pregunta nos llega sobre todo al principio de los proyectos. La organización pregunta qué normas debe cumplir el software, y la respuesta no está en una sola ley. Tener en cuenta esta dispersión en la fase de diseño es mucho más barato que poner parches después.
La pregunta "qué dice el derecho digital sobre esto" no tiene respuesta, porque no existe un único texto llamado derecho digital. Esto es lo primero que aprende cualquiera que trabaje en este ámbito, y lo más difícil de explicar a un cliente.
En Turquía, las actividades digitales se regulan en la intersección de al menos seis leyes distintas. Ninguna de ellas engloba a las demás. Todas funcionan con su propia lógica, su propio régimen sancionador y su propia autoridad de control. El resultado es este. No es posible elaborar una lista de obligaciones consultando un único texto, y un mismo hecho puede producir consecuencias simultáneas bajo más de un régimen a la vez.
Una violación de datos aparece en tres lugares distintos
Conviene verlo con un ejemplo concreto. Supongamos que se obtuvo acceso no autorizado a la base de datos de clientes de una empresa de comercio electrónico y los datos fueron extraídos.
La primera vía es administrativa. El artículo 12 de la Ley 6698 regula las obligaciones de seguridad de los datos, y el párrafo quinto de ese mismo artículo exige que la violación se notifique al Consejo. El Consejo evalúa la suficiencia de las medidas técnicas y administrativas adoptadas y, si las considera insuficientes, impone una multa administrativa.
La segunda vía es penal. El hecho de quien obtuvo el acceso puede constituir el delito de acceso a un sistema informático conforme al artículo 243 de la Ley n.º 5237, y la extracción de los datos puede constituir el delito de transmitir u obtener ilícitamente datos conforme al artículo 136. Esta investigación se desarrolla con independencia de la responsabilidad administrativa de la empresa.
La tercera vía es la de derecho privado. La persona cuyos datos fueron filtrados puede reclamar la reparación del daño sufrido. El último apartado del artículo 11 de la Ley reserva expresamente este derecho.
Las tres vías no son alternativas entre sí, funcionan al mismo tiempo. Haber pagado la multa del Consejo no pone fin a la investigación penal, y el resultado del proceso penal no resuelve por sí solo la reclamación de indemnización.
A qué pregunta responde cada ley
La forma más práctica de entender la dispersión de este ámbito es ver a qué pregunta responde cada texto.
La Ley 6698 responde a la pregunta "¿puede usted tratar este dato?". Aquí están las condiciones de tratamiento, el deber de informar, las medidas de seguridad y los derechos del interesado.
La Ley n.º 5651 responde a la pregunta "¿quién es responsable de este contenido?". Esta ley regula la distinción entre proveedor de contenido, proveedor de alojamiento, proveedor de acceso y proveedor de uso colectivo, así como los procedimientos de retirada de contenido y de bloqueo del acceso. El régimen de responsabilidad cambia por completo según cuál de estas cuatro condiciones tenga la persona.
La Ley n.º 5237 responde a la pregunta "¿es este hecho un delito?".
La Ley n.º 6563 responde a la pregunta "¿puede usted enviar esta comunicación comercial y qué está obligado a declarar como prestador de servicios?".
La Ley n.º 5070 responde a la pregunta "¿sustituye esta firma electrónica a la firma manuscrita?".
En un proyecto, normalmente todas estas preguntas surgen a la vez. Una decisión tomada mirando solo una de ellas genera ceguera respecto de las otras cuatro.
Competencia dispersa significa control disperso
Lo que complica aún más este panorama es que las distintas leyes están confiadas a organismos diferentes.
La Autoridad de Protección de Datos Personales supervisa las actividades de tratamiento de datos. El organismo turco de tecnologías de la información y las comunicaciones es competente en el ámbito de las comunicaciones electrónicas y participa en la aplicación de las decisiones de bloqueo de acceso. El Ministerio de Comercio es responsable de la aplicación de la normativa de comercio electrónico.
La consecuencia práctica de esto es la siguiente. En un único producto puede ser usted responsable ante más de una autoridad de control, y esas autoridades no están vinculadas por la decisión de la otra. Una opinión favorable de una de ellas no impide que la otra llegue a una conclusión distinta.
Dónde se comete el error en la práctica
La gran mayoría de los errores que veo en este ámbito comparten un rasgo común. La evaluación jurídica se hace después de haber tomado las decisiones técnicas.
El modelo de datos ya está construido, las tablas ya están creadas, las integraciones ya están escritas. Cuando el producto está a punto de salir a producción, se le dice al abogado "eche un vistazo, por favor". En esa fase, lo que puede decirse es limitado, porque cualquier cosa que se diga implica ya una corrección retroactiva, y esa corrección retroactiva plantea un problema aparte respecto de los datos recopilados hasta entonces.
Sin embargo, todas las preguntas siguientes podrían haberse respondido al construir el modelo de datos. Qué categorías de datos personales se tratarán. En qué base jurídica se apoyará cada categoría. Cuál será el plazo de conservación y qué componente lo aplicará. A qué tablas habrá que acceder cuando llegue una solicitud de supresión. Habrá transferencia internacional de datos.
Cinco preguntas. Todas pueden responderse en una sola reunión. El coste que surge cuando no se responden es muchas veces superior al coste de esa reunión.
La verdadera dificultad del ámbito
La dificultad del derecho digital no está en la complejidad de las reglas. Las reglas, leídas una por una, son comprensibles.
La dificultad está en saber en qué momento entra en juego cada regla. La decisión de un ingeniero de "guardemos también este campo, por si acaso hace falta" produce consecuencias bajo tres leyes distintas, y quien toma esa decisión la mayoría de las veces no lo sabe. La forma de cerrar esta brecha de conocimiento no es preparar un expediente de cumplimiento más grueso, sino que el jurista esté presente en la mesa donde se toma la decisión.