Construir al Final: Una Regla de Adquisición para Herramientas de Gobernanza de IA
Adoptar Primero, Respaldar lo que se Puede Adquirir, Construir Solo Cuando una Búsqueda Documentada Ha Fallado
La adecuación a la misión y el esfuerzo invertido no justifican nada. Lo único que justifica construir es una búsqueda que fracasó y quedó documentada.
La Reflexión
La secuencia es lo suficientemente familiar como para recitarla. Una brecha de gobernanza aparece durante una auditoría. Nada en el mercado encaja exactamente. Alguien ha construido algo adyacente antes. Aparece una hoja de cálculo, luego un script, luego una aplicación interna con dos mantenedores y sin hoja de ruta. Dieciocho meses después, soporta una obligación de cumplimiento y uno de los mantenedores se ha ido.
Nadie tomó una mala decisión. Cada paso fue localmente razonable, y el agregado es una dependencia sin financiación en una ruta de control regulada. La regla a la que me apego es: adoptar primero, respaldar lo que se puede obtener legítimamente por terceros, construir como último recurso. Fuerte en propósito, porque el reflejo que se opone es fuerte y el fallo que previene aparece años después de la decisión que lo causó.
Las Tres Puertas
La regla solo es útil como preguntas que alguien responde antes del primer commit.
¿Existe? No se trata de si un producto resuelve esto exactamente, que casi siempre es no y es la pregunta equivocada. ¿Resuelve algo el 70%, siendo el resto proceso y no software? La mayoría de las brechas de gobernanza se responden con una herramienta existente más una decisión que nadie quiere tomar, y construir nos permite evitar esa decisión. Busquen productos comerciales, proyectos de código abierto, organismos de estándares con implementaciones de referencia y aquello adyacente construido para un problema vecino. Este último contiene la mayoría de las respuestas perdidas.
¿Podemos soportarlo? Una herramienta que no podemos operar no es una respuesta. Esta puerta pregunta sobre licencias que sobreviven a nuestro caso de uso, mantenimiento que no depende de un voluntario ascendente, manejo de datos que cumple con nuestras obligaciones y una vía de salida. Una dependencia que no podemos abandonar es una que hemos valorado mal. Respaldar también significa contribuir: financiar o parchear el último 30% suele ser mejor que construir el 100%, y deja la capacidad donde alguien más la mantiene.
¿Sobrevive la brecha al contacto? Después de las primeras dos puertas, reformúltenla en una frase. A menudo se ha reducido a algo que no es un problema de software: una política nunca escrita, un umbral que nadie establecería, un rol ausente en el organigrama. Esas cosas no se cierran construyendo. Construir sobre ellas produce una herramienta que codifica la decisión no tomada y dificulta revisarla.
La Adecuación a la Misión No Justifica Nada
Aquí llegan dos argumentos, y ambos deben ser rechazados claramente.
El primero es la adecuación a la misión. "Esto es central para lo que hacemos, así que debemos hacerlo nosotros". Ser dueño y construir son decisiones diferentes, y la segunda no se desprende de la primera. Una empresa cuya misión es el juicio legal no escribe, por lo tanto, su propio sistema de gestión documental. La competencia central aboga por controlar la interfaz y los datos, no por ser el autor de la implementación.
El segundo es el esfuerzo hundido. "Ya hemos dedicado cuatro meses a esto". Cuatro meses nos hablan del pasado y nada de los próximos cuatro. Parece que lo hacen, por eso esto necesita una regla y no una llamada de juicio en el momento.
Ambos son del tipo razonable que sobrevive a una reunión, por lo que las puertas se responden primero por escrito.
Documentar la Búsqueda
Las puertas valen poco por sí solas. Lo que hace que la regla se potencie es el artefacto: un registro de lo que se buscó, lo que se encontró y por qué no encajó. Seis meses después, alguien encuentra la misma brecha desde otra perspectiva, y sin el registro, realiza la misma búsqueda mal y construye una segunda herramienta.
Un registro utilizable tiene cuatro partes y cabe en una página:
- La brecha, en una frase, como se declaró antes de la búsqueda.
- Lo que se evaluó, incluyendo las herramientas adyacentes consideradas y descartadas.
- Por qué cada una falló una puerta, nombrando cuál.
- La fecha, porque esto caduca.
Esa última parte importa más de lo que parece: una decisión de construir justificada por una búsqueda de hace dos años no está justificada por nada.
Lo Ejecutamos Nosotros Mismos
Prefiero exponer la versión incómoda antes que la halagadora. Cada componente de nuestra cartera existe porque faltaba una capacidad en el trabajo real y la búsqueda no dio resultado. Esa es exactamente la afirmación que un fundador hace con demasiada facilidad, por lo que la regla se aplica más fuertemente a nosotros. La prueba de adoptar primero no se vuelve más fácil porque ya escribimos la cosa. Cuando un estándar o proyecto externo puede cubrir parte de lo que construimos, el movimiento correcto es adoptarlo y retirar el nuestro. Algunas de esas decisiones siguen abiertas.
Cuándo Está Bien Construir
La regla no es "nunca construir". Construir es lo último y se hace deliberadamente, cuando la búsqueda fracasó en el registro, la brecha sobrevivió a la tercera puerta y la construcción tiene un dueño, un presupuesto y un estado final. Lo que previene es el otro camino, donde llegamos a una dependencia interna personalizada sin haber decidido nunca hacerlo.
La próxima vez que aparezca una brecha de gobernanza, el primer artefacto no debe ser un prototipo. Debe ser la página que dice lo que ya existe.
¿Listo para saber qué brechas de capacidad son reales antes de construir para ellas? Conozca PAICE para organizaciones o haga una evaluación individual para verlo por sí mismo.
Lecturas Recomendadas
- Gobernanza con IA Collaboration - Donde termina la política y comienza la herramienta
- Construyendo su Kit de Herramientas de IA Collaboration - Ensamblando lo que ya existe
- Estudio de Caso para el Negocio de la IA Collaboration - Lo que necesita la adquisición
- Guía Ejecutiva para la Preparación de IA Collaboration - Lo que vale la pena poseer
¿Curioso pero con poco tiempo?
Realiza el PAICE Pulse de 3 minutos — una verificación rápida de confianza que muestra cómo percibes tu propia postura de colaboración con IA. No requiere inicio de sesión.