Skip to content
Henry Rincón
CV (PDF)

Methods · Topic T1

How AI should be brought into an organization

It prints in full from the browser, on A4 or Letter.

Block 1

The problem

Bringing AI into an organization that is just starting so that what gets tested reaches operation, people adopt it and its value can be shown beyond the pilot.

Summary in three lines

  1. The starting point is the organization's problems, not the technology available: each opportunity states which problem it solves, for whom and how a good result will be recognized, and not every need calls for AI.
  2. A portfolio with shared criteria decides what moves forward; validation is progressive —proof of value, pilot, scale— and at each step a business metric can stop the initiative.
  3. Governance is the backbone of the program, not a final formality: roles and owners, risks and impact assessed from the design, and adoption measured in users and decisions, not in access.
Block 2

The map

From the organization's problem to an adopted, governed capability

Swipe to see the whole map.

From the organization's problem to an adopted, governed capabilityThe organization and its problem feed an opportunity portfolio that is filtered with prioritization criteria. What gets prioritized goes through a proof of value —which also decides whether to build, buy or compose with vendors and platforms— and a pilot with a metric, and only then scales into a capability in operation. That capability reaches trained people, its real use is measured as adoption, and that evidence decides whether to scale, adjust or stop; what gets adjusted goes back to the portfolio. Governance runs underneath: the organization appoints roles and owners, who answer for an AI management system; the system assesses risks and impact, and that analysis conditions every decision to scale.The organizationand its problem1Opportunityportfolio2Prioritizationcriteria3Proof of value4Pilot with ametric5Capability inoperation6Trained people7Measured adoption8Scale, adjust orstop9Roles and owners10AI managementsystem11Risks and impact12Vendors andplatforms13

Legend of shapes and colors

  • Actor — who does the work
  • Data — what is stored and read
  • Control — a rule that gets checked
  • Person — a person decides
  • External — what comes from outside

Reading the map, node by node

The organization and its problem feed an opportunity portfolio that is filtered with prioritization criteria. What gets prioritized goes through a proof of value —which also decides whether to build, buy or compose with vendors and platforms— and a pilot with a metric, and only then scales into a capability in operation. That capability reaches trained people, its real use is measured as adoption, and that evidence decides whether to scale, adjust or stop; what gets adjusted goes back to the portfolio. Governance runs underneath: the organization appoints roles and owners, who answer for an AI management system; the system assesses risks and impact, and that analysis conditions every decision to scale.

  1. Node 1 The organization and its problem (Person) — Who decides, which process falls short and what result is expected: the starting point, before any tool.
  2. Node 2 Opportunity portfolio (Data) — Each opportunity written as a problem, its users and the expected result, with its owner.
  3. Node 3 Prioritization criteria (Control) — Value, feasibility, available data, risk, third-party dependency, integration and capacity for adoption, the same for the whole portfolio.
  4. Node 4 Proof of value (Control) — The main hypothesis, tested at the lowest reasonable cost and risk, and the indicator's baseline set before the pilot.
  5. Node 5 Pilot with a metric (Control) — Real users and a result agreed beforehand; if it is not reached, the pilot is paused and reviewed.
  6. Node 6 Capability in operation (Actor) — The solution integrated into the process, with oversight, documentation and someone who answers when the result is not the expected one.
  7. Node 7 Trained people (Person) — Those who use the capability learn on their own processes and products, not on a generic demo.
  8. Node 8 Measured adoption (Control) — Users responsible for the process, recurring use and decisions that rely on the capability: real use, not access.
  9. Node 9 Scale, adjust or stop (Control) — The evidence of adoption and value decides; stopping after properly invalidating a hypothesis is not a failure.
  10. Node 10 Roles and owners (Person) — The business answers for the purpose and the results; data, security, risk, compliance and technology step in according to the initiative.
  11. Node 11 AI management system (Control) — Policies, objectives, processes, controls and continual improvement: AI treated as a capability that is managed, not as a sum of projects.
  12. Node 12 Risks and impact (Data) — The consequences of a wrong answer or an unwanted action, vendor dependency and the effect on people and processes.
  13. Node 13 Vendors and platforms (External) — What already exists outside: it is bought or composed when it meets the need with less operation of one's own.

Connections

  • from The organization and its problem to Opportunity portfolio (raises)
  • from Opportunity portfolio to Prioritization criteria (is filtered)
  • from Prioritization criteria to Proof of value (prioritizes)
  • from Vendors and platforms to Proof of value (composes)
  • from Proof of value to Pilot with a metric (validates)
  • from Pilot with a metric to Capability in operation (scales)
  • from Capability in operation to Trained people (reaches)
  • from Trained people to Measured adoption (real use)
  • from Measured adoption to Scale, adjust or stop (evidence)
  • from Scale, adjust or stop to Opportunity portfolio (returns)
  • from The organization and its problem to Roles and owners (appoints)
  • from Roles and owners to AI management system (answers for)
  • from AI management system to Risks and impact (assesses)
  • from Risks and impact to Scale, adjust or stop (conditions)
Block 3

The phases

  1. Phase 1

    Start from the company's problems, not from the technology

    Inputs

    • The processes, decisions and results that fall short of expectations today.
    • The capabilities and data the organization already has.

    Activities

    • Map the process as it is executed, not as the manuals describe it, before proposing a solution.
    • Write each opportunity as a problem, its users, the expected result and an owner.
    • Separate what a process improvement, a rule or an analytics product can solve from what calls for AI.

    Artifacts

    • The written opportunities, with their problem and their owner.
    • The map of the executed process.
    Who decides
    Leadership, with the owner of each process.
    Control that closes the phase
    No opportunity enters the portfolio without stating which problem it solves and for whom.
    Evidence

    At Fundación CTIC each opportunity first had to state which problem it solved and for whom; with that rule more than 10 were identified and half of them were formally evaluated.

  2. Phase 2

    Prioritize the AI use cases with shared criteria

    Inputs

    • The opportunity portfolio.
    • The prioritization criteria, agreed before scoring.

    Activities

    • Score each case on value, feasibility, available data, risk, third-party dependency, integration and capacity for adoption.
    • Choose the solution pattern: not every AI initiative needs an agent.
    • Open a file for each prioritized initiative.

    Artifacts

    • The prioritized portfolio.
    • The file with its owner, expected results, initial risks and evaluation criteria.
    Who decides
    Whoever sponsors the portfolio, with the areas that will use it.
    Control that closes the phase
    Every prioritized initiative has an owner, expected results, initial risks and evaluation criteria written down before it starts.
    State of the field

    The Cloud Adoption Framework asks to evaluate each use case on feasibility, strategic value and resources, and to score it on business impact, technical complexity, resource requirements and alignment with goals.[2]

  3. Phase 3

    Validate with a proof of value before building

    Inputs

    • The prioritized initiative and its main hypothesis.
    • The indicator the case promises to move.

    Activities

    • Test the hypothesis with a data exploration, a controlled test or a limited prototype.
    • Start with an internal case, with no customers exposed.
    • Set the indicator's baseline before the pilot.

    Artifacts

    • The hypothesis confirmed or discarded, in writing.
    • The baseline.
    Who decides
    The owner of the initiative.
    Control that closes the phase
    If the hypothesis does not hold, the initiative is stopped or redesigned: stopping is also a result.
    Evidence

    At Fundación CTIC the aim is for validation to be progressive: a data exploration, a controlled test or a limited prototype can generate enough evidence to move forward, change the approach or stop before committing more resources.

  4. Phase 4

    Pilot with a business metric that can stop it

    Inputs

    • The approved proof of value and its baseline.
    • The result agreed with the sponsor.

    Activities

    • Run with real users in a bounded scope.
    • Measure against the baseline, not against an impression.
    • Write down the decision: scale, change course or stop.

    Artifacts

    • The pilot's result against what was agreed.
    • The written decision, with its owner.
    Who decides
    The sponsor, with the process owner.
    Control that closes the phase
    A pilot that does not reach the agreed result is paused and reviewed; nothing scales by inertia.
    State of the field

    The Cloud Adoption Framework proposes using business metrics as decision gates: if a pilot doesn't meet the agreed-upon results, the work is paused and the use case reassessed.[4]

  5. Phase 5

    Scale with governance: roles, risks and impact

    Inputs

    • The approved pilot.
    • The policies and obligations that apply to the organization.

    Activities

    • Assign roles, responsibilities and authorities: not every AI decision belongs to the technical team.
    • Assess the system's risks and impact before extending it.
    • Record the system in the inventory, with its life cycle.

    Artifacts

    • The risk matrix and the impact assessment.
    • The inventory of AI systems.
    Who decides
    Senior leadership, with the business, data, risk and technology owners.
    Control that closes the phase
    No system goes into operation without an owner, a risk and impact assessment and its place in the inventory.
    Evidence

    At Fundación CTIC the strategy is structured following ISO/IEC 42001, in its UNE-ISO/IEC 42001:2025 adoption, with more than 20 instruments of the management system; one of its matrices is the risk analysis of each use case, and the standard also requires assessing the impact of AI systems.

  6. Phase 6

    Train, measure adoption and decide whether to scale, adjust or retire

    Inputs

    • The capability in operation.
    • The people who are going to use it.

    Activities

    • Train on people's own processes and products, as part of the delivery.
    • Measure real use: users with responsibility, recurrence and supported decisions.
    • Compare against the baseline and decide whether to scale, adjust or retire.

    Artifacts

    • The training program.
    • The reading of adoption and value.
    Who decides
    The process owner.
    Control that closes the phase
    What is not used or does not move the indicator goes back to the portfolio to be adjusted or retired.
    Evidence

    At Banco Pichincha the training of 12 professionals on their own products was part of the product and contributed to a 20% increase in productivity in preparing and using information.

Block 4

The design decisions

  1. How to bring AI to a company that is just starting: through its problems, not the tool

    When yes
    When a company is just starting with AI, the first inventory is of problems, processes and decisions; to bring AI to the company, each one is written with its user and expected result.
    When no
    When the initiative arrives pushed by a vendor or by enthusiasm for a tool: it does not enter the portfolio until it states which problem it solves.

    Why

    Evidence

    At Inglopres the ERP rollout (Odoo) showed that digitizing a process without reviewing it can carry its inconsistencies into the technology: the executed process was mapped and modeled in BPMN before configuring the solution.

    State of the field

    The Cloud Adoption Framework asks leaders to define the business outcomes AI is expected to support, and the AI strategy to document priorities, decision rights and how the value of the investment is measured.[1]

  2. What criteria to use to prioritize AI use cases

    When yes
    To prioritize AI use cases, the criteria are potential value, feasibility, data availability, risk level, third-party dependency, integration complexity and capacity for adoption, applied to the whole portfolio.
    When no
    When a use case is chosen only for being the most innovative: the criteria look for learning and value without exceeding the organization's capacity to implement, oversee and sustain it.

    Why

    Evidence

    At Fundación CTIC use cases are prioritized with those seven criteria: of more than 10 opportunities half were formally evaluated and some were already prioritized, and that proportion is the filter working, not a lack of ideas.

    State of the field

    Microsoft recommends that an AI Center of Excellence create an intake and prioritization process with consistent criteria for business value, technical feasibility and resource requirements, and maintain a prioritized initiative backlog.[3]

  3. Proof of value, pilot and scale: when to move forward and when to stop

    When yes
    When there is uncertainty about the data, the technology or adoption: the main hypothesis is tested at the lowest cost and the baseline is set before the pilot.
    When no
    When the need is met by a known, low-risk instrument: a proof of value only delays what is already clear.

    Why

    Evidence

    At Fundación CTIC stopping or redesigning a case after properly invalidating a hypothesis does not count as a failure: that most of the evaluated cases have not moved forward yet is the filter working.

    State of the field

    The Well-Architected Framework warns that, without strong leadership and a clear plan, AI efforts can quickly become fragmented and might not evolve beyond a proof of concept.[10]

  4. Build, buy or compose: the solution with the least operational ownership

    When yes
    Buy or compose when an existing capability meets the need with less operation of one's own; build when the difference lies in one's own process and someone will run it.
    When no
    Building an agent for a problem that a process improvement, an analytics product or a conventional automation can solve.

    Why

    Evidence

    At Fundación CTIC the evaluation must first determine whether AI is needed and which kind of capability fits, so as not to build agents where a simpler instrument, such as an analytics product in Power BI, is enough.

    State of the field

    The Cloud Adoption Framework recommends approving the solution that meets the requirements with the least operational responsibility: greater customization generally requires more specialized skills and greater operational ownership.[1]

  5. Center of excellence or federated model: centralize to start, delegate as it matures

    When yes
    A central center of excellence when the organization is just starting: it concentrates expertise and sets standards; as it matures, it advises and the areas build within those limits.
    When no
    A central team that approves everything when requests are already queuing and bottlenecks appear: governance is built into the platform and the center stops being a checkpoint.

    Why

    Evidence

    At Fundación CTIC the strategy seeks to establish a governance framework that splits the decisions: the business must answer for the purpose and the results, data owners for quality and conditions of use, and security, risk, compliance and technology must step in according to the initiative.

    State of the field

    Microsoft recommends starting with a centralized AI Center of Excellence and moving to an advisory role as adoption matures; for agents, most organizations blend centralized and federated structures by pattern, and the Fabric roadmap finds the unified or federated models most effective.[3][5][9]

  6. How to measure the adoption of a new tool: users, use and decisions

    When yes
    To measure the adoption of a new tool: users responsible for the process, recurring use and decisions that rely on it, with training as part of the delivery.
    When no
    Counting access or assigned licenses as if they were adoption.

    Why

    Evidence

    Adoption has been measured four times, with different users and decisions: more than 50 users at Banco Pichincha, more than 25 key users at TransMilenio, more than 15 roles with direct responsibility at Cafam and some 20 leaders of some 15 processes at Fundación CTIC.

    State of the field

    In the employee AI enablement pattern, Microsoft separates the early adoption signals —active users against assigned licenses, weekly use, retention— from the lagging signals of business value: adoption is the earliest signal and value is the proof.[6]

Block 5

What is new in 2026

  • State of the field

    Value is decided at gates, not at the end

    What changes from common practice

    Before development, the indicators' baseline is set; at each stage the business metric decides whether to continue, change direction or stop, and after deployment the evidence decides whether to scale, improve or retire.[4][7]

    Judgment

    A proof of value without a baseline proves nothing: it only shows that something works.

  • State of the field

    The AI strategy as a charter with decision rights

    What changes from common practice

    The AI strategy documents the organization's priorities, decision rights and how the value of the investment is measured, and broad access to approved capabilities is paired with training.[1]

  • State of the field

    ISO/IEC 42001 as the backbone of the program, not only of compliance

    What changes from common practice

    The standard specifies how to establish, implement, maintain and continually improve an AI management system, and offers a structured way to manage risks and opportunities that balances innovation with governance.[11]

    Judgment

    A management system born with the first use case tends to cost less than one that arrives to audit what is already in operation.

  • State of the field

    The center of excellence moves from control to advice

    What changes from common practice

    The AI Center of Excellence starts centralized to concentrate expertise and, when delays and bottlenecks appear, moves to advising and setting guardrails while product teams deliver; for agents, the structure is chosen by adoption pattern and maturity, not by org chart.[3][5]

  • State of the field

    Governance built into the workflow

    What changes from common practice

    Centralized standards with distributed implementation: responsible AI checkpoints at design reviews, testing and prelaunch approvals, and formal sign-offs for high-risk AI.[12]

  • State of the field

    Twelve adoption areas, transferable to AI

    What changes from common practice

    The Fabric adoption roadmap organizes adoption into twelve areas —among them data culture, sponsorship, content ownership, center of excellence, governance, user enablement, community and change management— and distinguishes three content ownership strategies.[8][9]

    Judgment

    The framework was born for analytics and its areas serve AI almost unchanged: sponsorship, ownership and enablement weigh more than the tool.

Block 6

Failure modes and how to anticipate them

  • What breaks
    Pilots that never get past the demo
    How it shows up
    Several proofs of concept open and none with an owner or a metric to scale.
    Control that catches it
    Every pilot is born with its baseline, its owner and the decision that closes it.
  • What breaks
    The tool picks the use case
    How it shows up
    The initiative arrives with the product already chosen and no written problem.
    Control that catches it
    No opportunity enters the portfolio without a problem, a user and an expected result.
  • What breaks
    An agent for a problem that needed a rule
    How it shows up
    Operating cost and risk out of proportion to the result.
    Control that catches it
    The evaluation first decides whether AI is needed and which capability fits.
  • What breaks
    Isolated experiments by area
    How it shows up
    Similar solutions built twice, with different data and criteria.
    Control that catches it
    One shared portfolio with the same criteria and an inventory of AI systems.
  • What breaks
    Governance arrives late
    How it shows up
    Risks, bias or information exposure discovered once in operation.
    Control that catches it
    Roles, risks and impact assessed from the design, inside the management system.
  • What breaks
    Assigned licenses mistaken for adoption
    How it shows up
    Plenty of access and few decisions that change.
    Control that catches it
    Adoption measured in responsible users, recurring use and supported decisions.
  • What breaks
    A center of excellence that becomes a bottleneck
    How it shows up
    Requests queuing and teams going around it.
    Control that catches it
    Moving to an advisory role with governance built into the platform.
  • What breaks
    The capability depends on whoever built it
    How it shows up
    Nobody else can run or explain it when the team changes.
    Control that catches it
    Documentation, owners and knowledge transfer as part of the delivery.
Block 7

Metrics and controls

  • What is measured
    Opportunities with a written problem and owner
    Threshold
    All of those entering the portfolio.
    Who approves the step to production
    Whoever sponsors the portfolio.
  • What is measured
    Initiatives with evaluation criteria set beforehand
    Threshold
    None starts without them.
    Who approves the step to production
    Whoever sponsors the portfolio.
  • What is measured
    Proof-of-value hypothesis
    Threshold
    A written decision: move forward, adjust or stop.
    Who approves the step to production
    The owner of the initiative.
  • What is measured
    The pilot's indicator against its baseline
    Threshold
    The result agreed before starting.
    Who approves the step to production
    The pilot's sponsor.
  • What is measured
    Risks and impact assessed
    Threshold
    Before going into operation.
    Who approves the step to production
    Risk, compliance and the system owner.
  • What is measured
    Active users against intended users
    Threshold
    A target set before launch.
    Who approves the step to production
    The process owner.
  • What is measured
    Decisions or tasks supported by the capability
    Threshold
    Growing against the baseline.
    Who approves the step to production
    The process owner.
  • What is measured
    AI systems in the inventory, with their life cycle
    Threshold
    All of those in operation.
    Who approves the step to production
    Whoever runs the management system.

The thresholds are examples of the method, not figures from a specific project.

Block 8

Evidence from projects

  • EvidenceLevel: Real use

    Fundación CTIC: an AI portfolio with shared criteria

    Since March 2025 Fundación CTIC's institutional AI strategy has been structured: more than 10 opportunities identified, half of them formally evaluated and some already prioritized; of these, the first ones already have owners, expected results, initial risks and evaluation criteria documented.

    See where
  • EvidenceLevel: Under construction

    Fundación CTIC: the management system under ISO/IEC 42001

    The strategy follows the principles and requirements of ISO/IEC 42001, with more than 20 instruments of the management system and, under construction, a progressive inventory of AI systems and a governance framework that seeks to split roles between the business, the data owners and the risk, security and technology functions.

    See where
  • EvidenceLevel: Real use

    The app factory: two written approvals

    In the AI-APPs pipeline no application moves forward without two written approvals —the current priority and the product vision— and critical decisions keep explicit human owners: of 12 initiatives conceived, only 7 have a repository.

    See where
  • EvidenceLevel: Real use

    The portfolio, a product of the factory

    Ten sister applications, 11 agents, 7 research lines and 6 dashboards —34 pieces, not counting this site— come out of a pipeline with two houses, a factory agent, four CI jobs and a sheet contract.

    See where
  • EvidenceLevel: Real use

    Banco Pichincha: adoption and training as part of the product

    In 2023, more than 50 business users adopted the team's solutions, with a reported 25% improvement in decision-making; training 12 professionals on their own products contributed to 20% higher productivity.

    See where
  • EvidenceLevel: Real use

    TransMilenio: adoption by key users

    Between July 2021 and May 2022, at C&M Consultores, Power BI was adopted by more than 25 key users —people responsible for scheduling, monitoring and decisions, not just people with access— and helped improve the efficiency of the analytical processes by 35%.

    See where
  • EvidenceLevel: Real use

    Cafam: a new technology that enters through the process

    Between October 2020 and June 2021, in the Oracle WMS Cloud implementation, a team of 20 people tested the system and the process at the same time; the control BI was adopted by more than 15 senior decision-makers in the project and improved the accuracy of test tracking by 50%.

    See where
  • EvidenceLevel: Real use

    Inglopres: the ERP as a precedent

    At Inglopres (2015–2017), an ERP rollout (Odoo) took the operation from scattered records to a single place; before configuring it, the executed process was mapped and modeled in BPMN.

    See where
Block 9

Limits and scope

  • Evidence

    At Fundación CTIC the strategy and the management system are still in a progressive process of structuring and consolidation, and their figures are published as approximations.

  • Evidence

    At Fundación CTIC there is no team of direct reports: the work integrates whole processes, with some 20 leaders of some 15 processes, and the improvement plans are carried out by the process owners.

  • Evidence

    The app factory is the author's own work, built in public outside employment: it shows how what gets built is approved and governed, not an implementation in a client organization.

  • Evidence

    The center of excellence and the decision to build, buy or compose appear here as state of the field and criterion: the evidence from Fundación CTIC is the portfolio with shared criteria and the governance framework it seeks to establish.

  • Evidence

    The Inglopres ERP and the Cafam WMS are precedents of technology implementation, not of AI: what they teach is that a new technology enters through the process.

  • Judgment

    What should be done differently today: set the baseline and the metric that stops a pilot before the first proof of value, not afterwards.

  • Judgment

    An AI program is judged by the decisions it changes, not by the pilots it opens.

Block 10

Sources and review date

  1. [1]
    AI adoption

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/strategy

  2. [2]
    Plan for AI adoption

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/plan

  3. [3]
    Establish an AI Center of Excellence

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/center-of-excellence

  4. [4]
    Business plan for AI agents

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/business-strategy-plan

  5. [5]
    Choose your CoE structure and operating model

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/agents/center-of-excellence/operating-models

  6. [6]
    Employee AI enablement pattern

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/agents/adoption-patterns/pattern-employee-ai-enablement

  7. [7]
    Agentic AI maturity model - Business strategy

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/agents/adoption-maturity-model/maturity-model-business-process

  8. [8]
    Microsoft Fabric adoption roadmap

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap

  9. [9]
    Microsoft Fabric adoption roadmap: Center of Excellence

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-center-of-excellence

  10. [10]
    Build an AI Strategy for your SaaS Business

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/well-architected/saas/ai-strategy

  11. [11]
    ISO/IEC 42001:2023 Artificial Intelligence Management System Standards

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/compliance/regulatory/offering-iso-42001

  12. [12]
    Responsible AI Policies

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/responsible-ai-policies