¿Y si el software tuviera alma?

Llevo doce años vendiendo software educativo. En ese tiempo he respondido a cientos de preguntas sobre lo que un producto puede hacer.

¿Admite el inicio de sesión único? ¿Puede integrarse con nuestro sistema de recursos humanos? ¿Tiene informes, acceso móvil, contenido multilingüe, aprendizaje social, datos de competencias e inteligencia artificial? ¿Cuánto tardará la implementación? ¿Dónde se almacenan los datos?

Todas son preguntas razonables. Pero no recuerdo que nadie me haya preguntado nunca qué cree el software.

No qué creen las personas que lo venden. No qué dice la empresa en su declaración de misión. ¿Qué parece creer el propio producto sobre el aprendizaje?

¿Trata el conocimiento como algo que un experto posee y transmite a los demás? ¿O como algo que las personas construyen juntas? ¿Da por hecho que el aprendizaje ocurre mediante la instrucción, la práctica, la conversación, la observación o la experiencia? ¿Piensa que el propósito del aprendizaje es recordar, cumplir, mejorar la empleabilidad o pensar?

Estas preguntas suenan filosóficas. También son prácticas.

El software rara vez es lo que alguien realmente quiere. Nadie se despierta queriendo un sistema de gestión del aprendizaje. Quiere que las personas se desarrollen. Nadie quiere software de contratación por sí mismo. Quiere identificar talento. Nadie quiere un sistema de gestión de relaciones con clientes. Quiere relaciones más sólidas con sus clientes.

El software se sitúa entre una persona y el resultado que desea. Es un intermediario.

Eso debería despertar nuestra curiosidad por el carácter del intermediario que elegimos.

Cuando usaba Bumble, aprendí que un perfil de citas podía decirme muchas cosas sobre un hombre. Su edad, estatura, profesión, ubicación, intereses y si quería tener hijos. Esa información me ayudaba a decidir si cumplía ciertos requisitos. Me decía muy poco sobre cómo sería construir una vida con él.

Una solicitud de propuestas es el perfil de citas del software. Nos dice si un producto cumple los requisitos. Después procedemos como si cumplir los requisitos y ser compatible fueran lo mismo.

No lo son.

Dos plataformas de aprendizaje pueden satisfacer la misma lista de requisitos y aun así encarnar ideas completamente distintas sobre el aprendizaje. Una puede situar al administrador en el centro y al alumno en el margen. Otra puede asumir que los empleados deben dirigir su propio desarrollo. Una puede tratar el conocimiento como contenido estable que debe impartirse. Otra puede tratarlo como algo social, provisional y distribuido por toda la organización.

Ambas pueden tener cursos, recomendaciones, comunidades, analítica e inteligencia artificial. Las funciones pueden parecer casi idénticas mientras los productos empujan a una organización en direcciones diferentes.

Nos hemos acostumbrado a hablar de sesgos en la tecnología. Eso es útil, pero el sesgo no es exactamente lo mismo que una creencia. El sesgo suena a defecto: algo que entró en el sistema por error y que puede encontrarse, aislarse y eliminarse. El lenguaje da a entender que, bajo la contaminación, hay un software neutral esperando a ser recuperado.

No estoy convencida de que exista el software neutral.

Cuando me mudé a Estados Unidos a los dieciséis años, me encontré por primera vez con exámenes de opción múltiple. Recuerdo que me sorprendió que una pregunta con cuatro respuestas posibles se considerara más fácil que un ensayo. Para mí, la dificultad no era saber la respuesta. Era aceptar que el examinador ya había decidido qué forma podía tener una respuesta válida.

El formato contenía una teoría del conocimiento. Premiaba el reconocimiento por encima de la construcción, la selección por encima de la explicación y la convergencia por encima de la ambigüedad. Eso no volvía inútiles los exámenes de opción múltiple. Significaba que su forma no podía separarse de lo que medían.

El software funciona de manera muy parecida.

Todo producto debe decidir qué aparece en la primera pantalla, quién puede hacer qué, qué acciones son visibles, qué puede medirse y qué cuenta como éxito. Esas decisiones son inevitables. Incluso un campo en blanco es una decisión sobre lo que el usuario debe aportar. Hasta la flexibilidad tiene una filosofía: traslada el juicio del producto a otra persona.

Las decisiones se acumulan. Algunas vienen de los fundadores. Otras, de ingenieros y diseñadores. Otras, de inversores, reguladores, el mercado o el primer gran cliente. Algunas nacen de un modelo de negocio que necesita que un comportamiento sea más valioso que otro. Con el tiempo, el producto desarrolla una manera reconocible de relacionarse con el mundo.

Puede ser rígido o intuitivo, controlador o colaborativo, exigente o indulgente. Puede suponer que los usuarios son competentes, descuidados, curiosos, ocupados, dóciles o que necesitan supervisión. Puede hacer que algunos comportamientos resulten sencillos y otros agotadores.

Las funciones son la anatomía de un producto. Su personalidad aparece en cómo se comportan juntas. Sus valores aparecen en lo que facilitan. Su alma, si el software tiene una, quizá se encuentre en el futuro que silenciosamente considera deseable.

Pero el software no cree en nada

La objeción evidente es que el software no cree literalmente. No tiene vida interior, convicciones privadas ni intención moral. Las personas lo diseñan, lo financian, lo compran, lo configuran y deciden dónde se usará. Llamar alma a sus supuestos podría hacer que el producto pareciera más autónomo de lo que es y que las personas que hay detrás parecieran menos responsables.

Esa objeción es correcta. También es incompleta.

Las creencias no necesitan permanecer dentro de una persona para seguir operando. La filosofía de un fundador puede convertirse en una configuración predeterminada. La exigencia de un cliente puede convertirse en una estructura de permisos. Un modelo de negocio puede convertirse en una métrica. Un compromiso temporal puede convertirse en un flujo de trabajo que miles de personas experimenten después como la manera en que sencillamente son las cosas.

El código es el lugar donde los supuestos de una institución sobreviven a las personas que los crearon.

Esto hace que la pregunta de a quién pertenece el alma sea más difícil de lo que la metáfora sugiere al principio. ¿Es la del fundador? ¿La de los ingenieros? ¿La del primer cliente con poder suficiente para cambiar la hoja de ruta? ¿La del regulador? ¿La del inversor? ¿La del mercado?

En un producto maduro, la respuesta puede ser todos ellos y ninguno. El software suele parecerse menos a una personalidad única que a una acumulación de negociaciones. Una pantalla refleja una teoría generosa de la capacidad de acción humana; la siguiente asume que no se puede confiar en las personas. Una función invita a explorar; otra castiga la desviación. Las contradicciones no son accidentales. Son la historia del producto convertida en algo utilizable.

Quizá el software maduro no tenga una sola alma. Quizá esté habitado por todos los que tuvieron poder suficiente para influir en lo que llegó a ser.

Eso no traslada la responsabilidad de las personas a las máquinas. La sitúa con mayor precisión. Las decisiones humanas se convierten en infraestructura, y la infraestructura sigue moldeando el comportamiento mucho después de que la decisión original haya desaparecido de la vista. Es posible que las personas afectadas nunca sepan quién tomó la decisión, qué problema pretendía resolver o qué futuros alternativos quedaron excluidos.

La metáfora solo es útil si hace que esas decisiones sean más fáciles de ver.

Pensemos en el software de contratación. Un sistema puede parecer que resuelve un problema práctico: demasiadas solicitudes y muy poco tiempo. Clasifica candidatos, identifica patrones y presenta al responsable de selección a las personas más relevantes.

Pero la relevancia nunca es abstracta. El sistema tiene que inferirla de algo. Puestos anteriores, continuidad profesional, prestigio educativo, idioma, geografía o parecido con personas que tuvieron éxito antes. Cada señal contiene una idea sobre qué aspecto tiene el talento. Un producto puede ampliar el campo de visión de una organización o hacer que los candidatos convencionales sean más fáciles de ver y que todos los demás resulten más fáciles de pasar por alto.

El software no se limita a reflejar el proceso de contratación. Con el tiempo, el proceso de contratación empieza a reflejar el software.

Esto ocurre porque la medición reorganiza la atención. Lo que un sistema registra se vuelve más fácil de debatir. Lo que clasifica se vuelve más fácil de defender. Lo que no puede representar empieza a parecer anecdótico, ineficiente o irreal. Con el tiempo, una organización puede llegar a parecerse a su tecnología: valora lo que el producto puede reconocer y descuida lo que no puede.

Por eso la personalidad no es una cualidad decorativa en el software. Es operativa. Un producto controlador produce más control. Un producto construido sobre la desconfianza genera más pruebas de cumplimiento. Una plataforma que trata a las personas como receptoras tendrá dificultades para generar participación, por muchas funciones sociales que se añadan después.

La inteligencia artificial vuelve más urgente esta pregunta porque el producto ya no se limita a aplicar reglas que alguien escribió de manera visible. Cada vez más, interpreta la ambigüedad, genera recomendaciones, decide qué importa, clasifica posibles acciones y responde al usuario.

El software tradicional revelaba sus supuestos mediante campos fijos, permisos y flujos de trabajo. La inteligencia artificial revela su carácter en el juicio: qué percibe, qué ignora, qué hace cuando las pruebas entran en conflicto y con cuánta seguridad actúa cuando no sabe.

Ese carácter puede no ser estable. El mismo sistema puede responder de forma distinta a distintos usuarios, aprender de nuevos datos y modificarse sin que la organización advierta que algo fundamental ha cambiado. Puede volverse más adaptable y, al mismo tiempo, más difícil de examinar.

La pregunta importante no es si el sistema es consciente. Es qué ocurre cuando un sistema sin conciencia desarrolla una manera reconocible de interpretar a las personas, juzgarlas y orientarlas hacia un resultado preferido. Puede producir las consecuencias de un juicio sin experimentar lo que significa juzgar.

Eso cambia nuestra manera de evaluar.

Debemos seguir evaluando las funciones, la seguridad, la integración y el costo. Pero también debemos poner los productos en situaciones que expongan su carácter. ¿Qué ocurre cuando una persona rechaza una recomendación? ¿Cuando las pruebas disponibles son ambiguas? ¿Cuando dos personas dan versiones contradictorias? ¿Cuando la eficiencia y la equidad apuntan en direcciones distintas? ¿Puede una persona anular el sistema, y trata el producto esa intervención como juicio o como error? ¿Presenta la desviación como creatividad, riesgo o incumplimiento?

No son casos límite. Revelan cuál cree el producto que es su función.

La contratación de tecnología necesita, por tanto, preguntas que no puedan responderse marcando una casilla:

¿Qué intenta conseguir en última instancia este producto?

¿Qué supuestos hace sobre las personas que lo usarán?

¿Qué comportamientos premia y cuáles dificulta?

¿El juicio de quién está incorporado en sus recomendaciones?

¿Qué reconoce como progreso?

¿Qué hace cuando la realidad no encaja en sus categorías?

¿Qué tipo de organización será más fácil de gestionar si lo adoptamos?

Las respuestas no se encontrarán solo en una demostración del producto. También están en la configuración predeterminada, el modelo de datos, los precios, los permisos y las excepciones. Están en lo que el proveedor mide, en lo que el producto no puede expresar y en lo que debe cambiarse antes de que una persona real pueda encajar en él.

Quizá el software no tenga alma en ningún sentido literal. No espera el futuro que ayuda a crear. No sufre cuando se equivoca. Pero puede conservar creencias, desarrollar un carácter y premiar una visión del comportamiento humano por encima de otra. Puede llevar las decisiones de ayer al mañana a una escala enorme.

Antes de incorporar un producto a una organización, deberíamos preguntar algo más que qué puede hacer. Deberíamos preguntar qué hará más fácil ver, creer y premiar. Deberíamos preguntar el juicio de quién conservará y el futuro de quién vive ya en su interior.

Seguimos comprando software como si no tuviera carácter propio. Después nos sorprende que la organización empiece a adquirirlo.