Lunes por la mañana. Acaba de entrar un objetivo nuevo y alguien lo dice en voz alta: ¿no miramos algo casi igual el año pasado? Todo el mundo lo recuerda a medias. Nadie sabe dónde está. Quien llevó aquella due diligence ya está en otra operación, o en otra firma, y a la hora de comer el equipo ha abierto una checklist nueva y empieza desde arriba.
Si has trabajado en operaciones, has vivido alguna versión de esa mañana. Queremos contar por qué se repite, por qué los remedios obvios nunca acaban de resolverlo y cómo creemos que sería una buena respuesta. Hacemos software para esto, así que lo decimos al final, y tú valoras el resto sabiéndolo.
Adónde va el conocimiento
Piensa en lo que aprende un equipo durante una due diligence y en dónde acaba todo eso.
El data room es del vendedor y se cierra con el proceso. El memorando de inversión recoge la conclusión, pero casi nunca el camino: los asuntos que parecían graves la segunda semana y quedaron resueltos la cuarta apenas dejan rastro. El informe de red flags se escribió para un comité y una fecha.
Y lo más valioso, la pregunta que hizo una compañera con más experiencia y a nadie más se le ocurrió, la cláusula que parecía estándar y no lo era, vive en comentarios, en llamadas, en un hilo de correo en el que estaban tres personas.
Nadie está siendo descuidado. Las operaciones van a plazo, y un plazo premia sacar el trabajo, no dejarlo bien archivado para quien venga detrás.
Lo que suelen intentar las firmas
Casi todas las firmas han probado alguna de estas soluciones, y cada una ayuda un poco.
Una unidad compartida con una carpeta por operación guarda bien los documentos. Pero para encontrar el precedente adecuado sigues teniendo que recordar en qué operación estaba, que es justo lo que se olvida.
Una biblioteca de checklists te dice qué preguntar. No te dice qué encontró el equipo la última vez que lo preguntó, ni por qué acabó importando.
Un buscador, incluso uno listo con un modelo de lenguaje encima, encuentra documentos que contienen las palabras que has escrito. No tiene ni idea de que los asesores fiscales contradijeron después un hallazgo de ese memorando, ni de que un socio corrigió hace dos operaciones cómo se estaba leyendo una cláusula de cambio de control.
Lo que tienen en común es que tratan cada operación como un expediente cerrado. Y sin embargo, lo que la hace útil para la siguiente es precisamente lo que pasó dentro: qué se comparó, qué se puso en duda, qué corrigió alguien.
Lo que de verdad ayudaría
Cuando hablamos con equipos de M&A, la lista de deseos es corta.
Primero, precedente fiable, y eso quiere decir precedente con su fuente: qué operación, qué documento, qué apartado, qué versión y qué se decidió al final. La vaga sensación de que esto ya lo vimos no aguanta un comité de inversión.
Segundo, un aviso a tiempo. Si el data room nuevo contradice algo que se encontró en una operación comparable, o le falta un documento que aquella sí tenía, quieren enterarse por el sistema, no por el comité.
Tercero, y es lo que más sorprende, memoria de las correcciones. Cuando un experto corrige una mala lectura, esa corrección debería llegar sola al siguiente equipo, no quedarse en la bandeja de entrada de quien recibió el correo.
Qué preguntar a cualquier sistema que lo prometa
Son las preguntas que haríamos a cualquier proveedor, y las que esperamos que nos hagan a nosotros.
¿Cada respuesta enseña el pasaje exacto del que sale? Un abogado o una analista debería poder comprobarla en segundos, sin tener que fiarse. Eso depende mucho más de cómo se recuperan los documentos que del modelo que redacta la respuesta, y por eso la generación aumentada por recuperación es tan buena como lo que recupera.
¿Los permisos se aplican al recuperar la información, o se arreglan después? El material de una operación es confidencial por naturaleza, a menudo bajo acuerdos que limitan quién puede verlo. Si el sistema guarda varias operaciones, lo que sabe del proceso de un cliente no puede aparecer nunca en el de otro.
¿Quién decide cuándo cambia lo que el sistema sabe? Si un hallazgo nuevo alteraría una conclusión existente, el sistema debería proponer el cambio y dejar que una persona lo apruebe, lo rechace o lo deshaga. Sobrescribir en silencio lo que sabe la firma no es aceptable.
¿Y puedes llevártelo todo? Lo que el sistema ha aprendido debería poder exportarse en formatos abiertos. Si algún día cambias de proveedor, el precedente se queda en la firma.
Un primer paso sensato
No empieces por todas las operaciones que ha hecho la firma. Elige un tipo de transacción que se repita, aquel en el que el equipo dice más a menudo que esto ya lo ha hecho. Reúne las operaciones cerradas de ese tipo, con sus memorandos y sus hallazgos finales.
Después siéntate con alguien que trabajó en ellas y escribid juntos veinte preguntas reales que haría una persona recién incorporada al empezar una due diligence parecida, con las respuestas acordadas de antemano. Añadid unas cuantas que el sistema debería rechazar, porque el material sencillamente no da para responderlas. Lanzadlas y mirad los pasajes que hay detrás de cada respuesta, no solo la respuesta.
La prueba que más nos gusta es esta: la décima due diligence de ese tipo debería ir más rápido que la primera. Si no es así, el conocimiento se sigue yendo por la puerta.
No es solo cosa de M&A
Lo hemos contado con una due diligence porque es donde el problema se ve más claro, pero la misma historia se repite en muchos otros equipos.
En legal, alguien negocia una cláusula de responsabilidad que ya se discutió con otro cliente hace dos años, y la posición que se acordó entonces está enterrada en un correo. En compras, se evalúa a un proveedor sin saber que otra planta tuvo problemas con él y lo dejó escrito en un informe que nadie encuentra. En ventas, se prepara una oferta desde cero cuando una muy parecida ya se ganó, o se perdió, por razones que alguien apuntó y nadie volvió a leer.
Cambian los documentos y cambia el vocabulario, pero el patrón es el mismo: el conocimiento se genera trabajando, se queda disperso y el siguiente equipo vuelve a empezar. Las preguntas de arriba sirven igual para cualquiera de esos casos.
Para que conste
Construimos uno de estos sistemas, BeAI 2nd Brain. M&A es una de las áreas para las que lo diseñamos, pero no la única.
Donde más esfuerzo ponemos es en la arquitectura, porque es lo que decide la calidad de las respuestas y lo bien que el sistema encaja en cada organización. Es flexible y modular: cada agente se compone de seis piezas explícitas, el modelo, el prompt, las herramientas, las habilidades, el middleware y la memoria a largo plazo, y cada una se ajusta por separado. Un agente nuevo es un documento de configuración, no una versión nueva de la plataforma.
En la práctica, eso nos permite elegir en cada despliegue la combinación que mejor responde con los documentos reales del cliente, y adaptar el sistema a sus fuentes, a su forma de trabajar y a sus reglas de acceso, en lugar de pedirle que sea él quien se adapte. Se despliega en el propio tenant de Azure del cliente, y los umbrales de calidad se acuerdan en cada proyecto y se comprueban con casos reales cuya respuesta se conoce de antemano, igual que la prueba que proponíamos arriba.
Todo lo anterior es lo que querríamos que un equipo nos exigiera.