Investigación y descubrimiento · Paso 01 · Cómo trabajamos
Cada compromiso de OpenQCore comienza con una investigación estructurada. Antes de proponer inteligencia artificial, automatización, software o infraestructura, estudiamos el problema como un sistema: sus objetivos, partes interesadas, flujos de trabajo, decisiones, datos, tecnologías, dependencias, limitaciones, riesgos y resultados medibles.
Nuestro proceso de descubrimiento combina investigación, pensamiento sistémico, análisis de ingeniería y razonamiento empresarial para pasar de un desafío observado a una definición del problema defendible.
Porque la primera pregunta no debería ser:
No es esta la pregunta
"¿Qué tecnología deberíamos desplegar?"
Esta pregunta, en cambio
"¿Qué problema estamos realmente resolviendo — qué evidencia lo respalda, qué lo causa, y qué resultado necesita cambiar?"
Investigación · Evidencia · Análisis de sistemas · Análisis empresarial · Medición
Por qué el descubrimiento es lo primero
La inteligencia artificial se ha vuelto sustancialmente más fácil de experimentar. Convertir la experimentación en valor organizacional medible sigue siendo considerablemente más difícil.
74%
de las empresas aún no habían demostrado ni escalado valor tangible con la IA.
BCG, Where's the Value in AI?, 2024 · n=1,000 altos ejecutivos.
La investigación de BCG de 2024, basada en 1,000 CxOs y altos ejecutivos de más de 20 sectores y 59 países, encontró que solo el 26% de las empresas habían desarrollado las capacidades necesarias para avanzar más allá de pruebas de concepto y generar valor tangible a partir de la IA.
Esto no significa que la tecnología sea ineficaz. Significa que la tecnología por sí sola es insuficiente.
Las organizaciones pueden comenzar con un modelo, plataforma o tecnología de automatización y solo más tarde descubrir que la restricción subyacente reside en otra parte: procesos fragmentados, datos inaccesibles, propiedad poco clara, limitaciones de integración, controles inadecuados, objetivos mal definidos o un problema que nunca se midió en primer lugar.
OpenQCore, por lo tanto, invierte la secuencia: la tecnología debe seleccionarse como consecuencia de comprender el problema — no como un sustituto de comprenderlo.
Un enfoque multidisciplinario
Los problemas organizacionales complejos rara vez pertenecen a una sola disciplina. OpenQCore los investiga desde tres perspectivas complementarias.
Observar · Plantear preguntas · Formular hipótesis · Probar · Validar
El razonamiento científico nos ayuda a distinguir observaciones de suposiciones, formular preguntas, examinar explicaciones alternativas y determinar qué evidencia apoyaría o contradiría una hipótesis. No asumimos que la primera explicación sea la correcta.
Sistemas · Interfaces · Datos · Dependencias · Restricciones · Confiabilidad
El análisis de ingeniería examina cómo interactúan los componentes dentro del sistema más amplio — software, infraestructura, datos, personas, procesos, interfaces, sistemas externos y dependencias operativas.
Esta perspectiva es coherente con el pensamiento moderno de la ingeniería de sistemas. ISO/IEC/IEEE 15288:2023 define los procesos del ciclo de vida del sistema aplicables a elementos de sistema individuales y a sistemas de sistemas, con la participación de las partes interesadas a lo largo de todo el ciclo de vida.
Objetivos · Economía · Procesos · Riesgo · Valor · Medición
El análisis empresarial determina por qué el problema importa. Examinamos el resultado deseado, las partes interesadas afectadas, el impacto operativo, las consideraciones económicas, las limitaciones organizativas y cómo se mediría la mejora.
La transformación por IA a menudo se discute principalmente en términos de modelos y algoritmos. La evidencia de implementación sugiere un panorama más amplio: la investigación de BCG de 2024 indicó que aproximadamente el 70% de los desafíos que encontraron las empresas en iniciativas de IA se relacionaban con las personas y los procesos, aproximadamente el 20% con la tecnología y solo el 10% con los algoritmos.
10%
Algoritmos
Estudio global BCG Build for the Future 2024 · n=1.000.
20%
Tecnología y Datos
Estudio global BCG Build for the Future 2024 · n=1.000.
70%
Personas y Procesos
Estudio global BCG Build for the Future 2024 · n=1.000.
Estos porcentajes son el marco de investigación de BCG, no una ley universal. Pero refuerzan un principio importante de la ingeniería: el modelo es un componente de un sistema sociotécnico más amplio. Para OpenQCore, por tanto, el descubrimiento examina no solo la capa de inteligencia, sino el entorno operativo en el que se introduciría esa inteligencia.
La metodología de investigación de OpenQCore
La fase de descubrimiento se lleva a cabo como una secuencia estructurada de investigación. La profundidad exacta varía según el compromiso, pero la estructura analítica permanece constante.
¿Qué resultado importa — y para quién?
Comenzamos identificando a las personas, funciones y sistemas afectados por el problema. La solicitud expresada por una organización no se trata automáticamente como el objetivo subyacente — "necesitamos un agente de IA" describe una posible implementación, aún no el problema de negocio o de ingeniería.
Examinamos
Partes interesadas · Tomadores de decisiones · Usuarios · Objetivos de negocio · Objetivos operativos · Incentivos · Dependencias · Requisitos conflictivos
Resultados
Modelo de partes interesadas y objetivos
¿Cómo opera realmente el sistema hoy?
Reconstruimos el proceso operativo actual en lugar de depender exclusivamente de cómo está documentado. Cuando procede, establecemos líneas base cuantitativas para el flujo de trabajo existente.
El análisis puede incluir
Procesos · Tareas · Decisiones · Transferencias · Colas · Excepciones · Intervención humana · Cuellos de botella · Retrabajo · Flujo de información
Resultados
Modelo operativo del estado actual
¿En qué entorno técnico estamos trabajando?
Examinamos la arquitectura que rodea el problema e investigamos el entorno de datos por separado. Esto importa porque una capacidad de IA que funciona experimentalmente puede seguir siendo inadecuada para producción si no se puede acceder a la información requerida de forma fiable, segura o con la calidad suficiente.
Examinamos
Aplicaciones · Servicios · APIs · Bases de datos · Infraestructura · Integraciones · Identidad · Seguridad · Dependencias externas — y la disponibilidad, accesibilidad, estructura, calidad, linaje, propiedad, cobertura, actualidad y sensibilidad de los datos
Resultados
Panorama de sistemas y datos
¿Qué entorno externo configura el problema?
Una solución técnicamente válida puede seguir siendo inapropiada desde el punto de vista operativo o comercial. El alcance depende del compromiso — un sistema sanitario regulado, una plataforma financiera y una herramienta interna de productividad no requieren las mismas formas de investigación contextual.
Cuando sea relevante, examinamos
Condiciones del mercado · Estructura de la industria · Regulación · Normas técnicas · Entorno competitivo · Panorama tecnológico · Expectativas de los clientes · Dependencias externas
Resultados
Modelo de contexto y entorno externo
¿Qué limita el espacio de soluciones?
Las restricciones se tratan como insumos de diseño en lugar de sorpresas descubiertas durante la implementación. También separamos explícitamente los hechos conocidos, las suposiciones, las incógnitas conocidas, las dependencias y los riesgos — porque la incertidumbre debe documentarse, no convertirse en certeza de forma silenciosa.
Identificamos
Restricciones técnicas, operativas, de presupuesto y de tiempo · Requisitos de seguridad, privacidad y regulatorios · Restricciones organizativas · Riesgos de adopción · Dependencias de integración · Limitaciones de datos
Resultados
Registro de restricciones, supuestos y riesgos
¿Qué debe cambiar exactamente?
El proceso de descubrimiento converge en una definición precisa del problema, que cubre la condición observada, la evidencia, las causas raíz, el sistema afectado, la línea base, el estado objetivo, los criterios de éxito, las restricciones y los no objetivos explícitos.
La definición incluye
Condición observada · Evidencia · Causas raíz · Sistema afectado · Línea base · Estado objetivo · Criterios de éxito · Restricciones · No objetivos
Resultados
Definición del problema validada
El ciclo de descubrimiento
El descubrimiento no es simplemente una lista de verificación completada una sola vez de izquierda a derecha.
Observar
Analizar
Mapear
Formular hipótesis
Validar
Definir
Una vez establecida la confianza suficiente: Problema validado → Estrategia y Arquitectura.
Aplicando la metodología
Un problema observado y su causa subyacente no son necesariamente lo mismo. Considere un ejemplo operativo simplificado.
Condición observada: Las solicitudes de los clientes requieren 48 horas para procesarse.
Evidencia del flujo de trabajo: Las solicitudes pasan por múltiples aprobaciones manuales.
Evidencia del sistema: La información relevante existe en aplicaciones desconectadas.
Evidencia de datos: La misma información se recupera y verifica repetidamente.
Hipótesis de la causa raíz: El flujo de trabajo fragmentado y la información inaccesible generan trabajo humano repetitivo.
En este punto, simplemente añadir una interfaz conversacional puede mejorar la experiencia de cara al cliente sin resolver la restricción subyacente en el procesamiento. La cuestión de ingeniería, por lo tanto, cambia de "¿Cómo añadimos IA?" a "¿Qué intervención cambia el mecanismo causal que produce el resultado indeseable?" — esa distinción es central en Investigación y Descubrimiento.
Observación: La verificación manual de documentos está asociada con un cuello de botella significativo en el procesamiento.
Hipótesis: Un flujo de trabajo de inteligencia documental controlado puede reducir la revisión manual mientras mantiene los controles de verificación requeridos.
Evidencia requerida: Documentos representativos · Tasas de error existentes · Patrones de excepción · Requisitos de revisión · Tiempos de procesamiento
Evaluación: Calidad de extracción · Tasa de excepciones · Tasa de revisión humana · Tiempo de procesamiento · Modos de fallo
Decisión: Apoyar · Modificar · Rechazar la hipótesis
El objetivo no es demostrar que la tecnología propuesta funciona. El objetivo es determinar si la evidencia justifica su uso.
Definir el éxito antes de la implementación
Si el éxito se define solo después de la implementación, casi cualquier resultado puede interpretarse como éxito. Por ello, OpenQCore establece líneas base relevantes y criterios de evaluación durante la fase de descubrimiento.
Tiempo de ciclo
¿Cuánto tiempo tarda el proceso?
Costo por operación
¿Qué recursos consume cada transacción?
Tasa de error
¿Con qué frecuencia el proceso produce un resultado incorrecto?
Rendimiento
¿Cuánto trabajo puede procesar el sistema?
Esfuerzo humano
¿Cuánta intervención manual se requiere?
Confiabilidad
¿Con qué consistencia funciona el sistema?
Calidad de la decisión
¿Con qué precisión o consistencia se toman las decisiones?
Tasa de automatización
¿Qué operaciones se pueden completar sin intervención manual?
Exposición al riesgo
¿Qué riesgo operacional, de seguridad o de cumplimiento existe?
Métricas de experiencia
¿Cómo afecta el proceso a los clientes, empleados u otros usuarios?
La estructura es simple: Línea base → Intervención → Objetivo → Medición → Evaluación.
Si no se puede describir el cambio deseado, no se puede evaluar de manera significativa el éxito de la solución.
La IA requiere un análisis de riesgo contextual
En los proyectos relacionados con IA, la fase de descubrimiento también examina si el uso propuesto de la IA es apropiado para el contexto en el que operará. El Marco de Gestión de Riesgos de IA de NIST organiza la actividad de gestión de riesgos de IA en torno a cuatro funciones y describe específicamente la gestión de riesgos como continua a lo largo del ciclo de vida de la IA en lugar de un ejercicio de cumplimiento puntual.
El marco también identifica características asociadas con una IA confiable, incluyendo validez y fiabilidad, seguridad, protección y resiliencia, responsabilidad y transparencia, explicabilidad e interpretabilidad, mejora de la privacidad y gestión de sesgos perjudiciales.
Uso previsto
Modos potenciales de fallo
Supervisión humana
Sensibilidad de los datos
Consecuencias de las decisiones
Seguridad
Confiabilidad
Requisitos de evaluación
Controles operativos
Requisitos de gobernanza
Esto no significa que todos los proyectos requieran la misma arquitectura de gobernanza. Los controles de riesgo deben ser proporcionales al sistema, a su contexto y a las consecuencias de una falla.
Evidencia antes de la recomendación
Buscamos la intervención que respalde la evidencia. La evidencia reciente sigue reforzando la importancia de rediseñar el trabajo en lugar de simplemente colocar IA sobre los procesos existentes.
~2/3
de las organizaciones aún no habían comenzado a escalar la IA en toda la empresa.
McKinsey, El estado de la IA: Encuesta global 2025.
39%
informaron un impacto en el EBIT relacionado con la IA a nivel empresarial.
McKinsey, El estado de la IA: Encuesta global 2025.
La misma investigación identifica el rediseño del flujo de trabajo como una característica clave de las organizaciones que obtienen mayor valor de la IA —una de las razones por las que OpenQCore investiga el modelo operativo que rodea la tecnología en lugar de considerar el despliegue en sí como el objetivo.
OpenQCore no inicia la fase de descubrimiento con una solución técnica predeterminada. La evidencia puede indicar que la intervención apropiada es el rediseño de procesos, la integración de sistemas, la ingeniería de software convencional, la arquitectura de datos, la automatización de flujos de trabajo, la analítica, la inteligencia artificial o una combinación de ellas. En algunos casos, la evidencia puede indicar que no está justificado construir nueva tecnología.
OpenQCore no recomienda la inteligencia artificial porque esté de moda. La recomendamos cuando el problema, la evidencia, la economía y las restricciones operativas justifican su uso — y decimos claramente cuando no lo hacen.
Problema → Evidencia → Requisitos → Restricciones → Intervenciones Candidatas → Evaluación → Enfoque Más Adecuado — no: IA → Buscar Dónde Usarla.
La selección de tecnología sigue a la investigación.
Los supuestos se identifican en lugar de presentarse como hechos.
Las conclusiones importantes deben estar conectadas con la evidencia que las respalda.
Cuando exista incertidumbre, deben considerarse explicaciones alternativas.
Los criterios de éxito se definen antes de la implementación cuando sea practicable.
Los aspectos desconocidos y las limitaciones permanecen visibles.
El nivel de análisis debe reflejar el coste, la complejidad y el riesgo de la decisión.
Qué produce el proceso de descubrimiento
La investigación y el descubrimiento no deben terminar con una presentación llena de observaciones. Deben producir artefactos que puedan informar una decisión de ingeniería. Dependiendo del alcance del compromiso, estos pueden incluir:
El contexto del problema, la evidencia, las observaciones y los hallazgos principales.
Quiénes se ven afectados, quiénes son los responsables de las decisiones y qué resultados importan.
Cómo se mueven el trabajo y la información a través de la organización hoy.
Aplicaciones, interfaces, fuentes de datos, dependencias y restricciones técnicas.
Explicaciones respaldadas por evidencia para la condición observada.
Rendimiento actual frente a indicadores operativos o técnicos relevantes.
Requisitos funcionales, técnicos, operativos y de gobernanza identificados durante el descubrimiento.
Viabilidad técnica, de datos, de integración y operativa cuando sea necesario.
Intervenciones potenciales priorizadas según la evidencia, el valor, la viabilidad y el riesgo.
Limitaciones conocidas, supuestos, dependencias y riesgos materiales.
Objetivos, métricas y enfoque de evaluación.
La Puerta de Decisión del Descubrimiento
El propósito del descubrimiento no es garantizar que un proyecto se lleve a cabo. Es determinar si debe hacerlo. Por lo tanto, un proceso de descubrimiento puede concluir con uno de varios resultados:
El problema está suficientemente definido, la evidencia respalda la intervención y parece factible un enfoque de ingeniería.
Persiste incertidumbre importante y se requiere evidencia adicional.
El problema original o la intervención propuesta no coinciden con lo encontrado en la investigación.
El objetivo sigue siendo válido, pero una intervención técnica u operativa diferente es más apropiada.
El valor esperado, la viabilidad o el riesgo no justifican la implementación.
No construir el sistema equivocado puede ser tan valioso como construir el correcto.
De la investigación a la arquitectura
La investigación y el descubrimiento no existen por separado del ciclo de vida de la ingeniería. Sus resultados se convierten en entradas para la siguiente fase: Evidencia → Definición del Problema Validada → Requisitos → Restricciones y Riesgos → Criterios de Éxito → Estrategia y Arquitectura.
La arquitectura no debe comenzar como una colección de tecnologías preferidas. Debe surgir de una comprensión defendible de lo que el sistema debe lograr, dentro de qué restricciones, para qué partes interesadas, con qué nivel aceptable de riesgo y frente a qué resultados medibles.
Paso 02
Convierte un problema validado en una dirección de sistema diseñada.
No necesitas llegar con una estrategia de IA. Trae el desafío operativo, la limitación técnica, la pregunta de investigación o el objetivo de negocio. Empezamos por determinar qué está ocurriendo realmente — y qué dicen las pruebas que debería ocurrir a continuación.
Referencias de investigación y metodológicas
Referenciamos estas fuentes directamente en lugar de ocultarlas, porque nuestra metodología se basa en principios establecidos de la investigación científica, la ingeniería de sistemas, la ingeniería de requisitos, el análisis de negocio y la gestión de riesgos.
Boston Consulting Group — Where's the Value in AI? (2024)
Basado en una encuesta a 1.000 CxO y altos ejecutivos en más de 20 sectores y 59 países; fuente de las cifras 74% / 26% y del principio 10–20–70 mencionado arriba.
McKinsey & Company — The State of AI: Global Survey 2025
Fuente de los datos sobre escalado y el impacto en el EBIT a nivel empresarial, y del hallazgo sobre la importancia del rediseño de flujos de trabajo entre las organizaciones de mayor rendimiento.
ISO/IEC/IEEE 15288:2023 — Ingeniería de sistemas y software — Procesos del ciclo de vida del sistema
La referencia principal de ingeniería para tratar los sistemas, sus elementos, el ciclo de vida y las partes interesadas de manera estructurada.
ISO/IEC/IEEE 29148:2018 — Ingeniería de requisitos
Especifica procesos y elementos de información para la ingeniería de requisitos a lo largo de los ciclos de vida de sistemas y software; ISO confirmó la edición como vigente tras una revisión en 2024.
NIST — Marco de Gestión de Riesgos de Inteligencia Artificial (AI RMF 1.0)
Apoya el pensamiento contextual sobre riesgos de IA mediante Gobernar, Mapear, Medir y Gestionar, con gestión continua de riesgos a lo largo del ciclo de vida de la IA. El AI RMF 1.0 de NIST está en revisión activa, por lo que nombramos la versión explícitamente en lugar de dar a entender que siempre es la última versión final.
