AI Consulting for Companies: Introducing AI into Business Processes Without Losing Control
- Andrea Viliotti
- 27 giu
- Tempo di lettura: 15 min
A simulated case: how I use the GDE to guide CEOs and management in corporate AI adoption — from process design to pilot, from full costs to governance and internal autonomy.
Confidentiality note The case described in this article is entirely hypothetical. I use a simulated company because real clients are protected by confidentiality agreements. Figures, suppliers, data, systems and outcomes are used to make the method visible; they are not a promise of results and do not replace legal, privacy, cybersecurity, accounting or technical audits for a specific company. |
Quick answer for CEOs and CFOs Introducing AI into business processes does not mean selecting the most promising software. It means understanding which decision must improve, with which data, responsibilities, real costs, compliance constraints and internal autonomy. In the simulated case, I show how I use the GDE to turn pressure around AI into a measurable, governable pilot that is useful to management. |
In this article you will find: a simulated business case, multi-vendor orchestration, IT integration, privacy and cybersecurity, full cost modelling, comparative pilot design, managerial coaching and scale/no-scale criteria.
1. AI adoption in companies: the risk is not only choosing the wrong software
When AI enters a company, the risk is not only buying the wrong software. The more serious risk is allowing the decision to be driven by a demo, a commercial urgency, a technology trend, compliance handled at the end, or a business case in which real costs are missing.
In my work I start from a different question: which business decision must improve, with which data, under which responsibilities, with which full costs, with which replaceable suppliers and with which capability that must remain inside the company?
The GDE is useful to me as a discipline of orchestration. I am not interested in proving that a generative model is impressive in a presentation. I am interested in understanding whether the company can improve a real process without losing control, margin, operational continuity, skills and the ability to choose the next technological step.
Where my work enters compared with vendors, integrators and specialist advisers A vendor tends to show what the platform can do. A system integrator tends to make implementation possible. DPOs, CISOs, lawyers, labour consultants and internal functions govern obligations, risks and responsibilities. My work comes before and across these layers: I help management turn the generic question “how do we introduce AI into the company?” into a verifiable decision on process, data, value, responsibility, vendor governability and internal capability. The result is not dependency on the consultant. It is a management team more capable of choosing, stopping, negotiating, measuring and scaling. |
Table 1 — Three entry points of the offer in the simulated case
Client need | How I enter | Management output |
“We do not know where to start” | AI Maturity Quick Check / AI Decision Check | Correct question, priorities, risks and first perimeter. |
“We have use cases, but we do not know whether we are ready” | AI Readiness Audit / Data & KPI Check | Data, owners, KPIs, integrations and areas to repair. |
“We are choosing vendors and pilot scope” | Strategy Sprint / Feasibility Lab | Perimeter, RFP, pilot design and gates. |
“The project is under tension” | AI Advisory | Board memo, vendor challenge and scale/no-scale decision. |
“We want internal autonomy” | Enterprise AI Adoption Program | Playbook, governance, lifecycle and training. |
2. A simulated AI consulting case: commercial pressure meets control
The hypothetical company is Alpina Meccanica S.r.l.: 118 employees, €31.8 million in revenue, 54% export, European and North American industrial clients, make-to-order production and strong pressure on response times for requests for quotation.
The selected process is quote-to-order: RFQ intake, drawing reading, historical retrieval, cost estimate, margin, commercial conditions, offer draft, approval and order handover. The board’s initial question sounds simple: “Can we use AI to respond faster to clients and improve margin and offer quality?”
The first meeting immediately shows that the question is not technical. The CEO wants speed: “We lost two tenders because we arrived late.” The CFO replies: “I do not want a project that starts with enthusiasm and ends in consulting, licences and internal hours that were not planned.” Sales wants fluidity. The technical manager fears wrong drawing reviews. The CISO warns: “If the vendor enters CRM, ERP and PDM without a clear perimeter, the problem is not AI; it is the company delegating its nervous system.”
In that room I do not take a position in favour of enthusiasm or caution. I turn the tension into verifiable decisions: what enters the pilot, what remains outside, who decides, which errors are acceptable, which errors block scale, which evidence the CFO needs and which competence must remain in the company.
Table 2 — The board’s question translated into operational decisions
Initial question | Correct question | Decision in the simulated case |
“How much faster will it be?” | Which sub-process accelerates without increasing rework, risk or lost margin? | AI on historical retrieval, technical dossier and offer draft; price and release remain human. |
“Which vendor do we choose?” | Which architecture allows us to change vendor, model or integrator? | Separation between data, orchestration, model, integration and human control. |
“How much will we save?” | Which cost changes, which value route and which denominator? | Complete cost vector and CFO one-page view. |
“Can we roll out?” | Which proof gate is passed and which is not? | Progressive scale only on product families with sufficient data, security and management autonomy. |
3. Business processes and AI: why quote-to-order must be decomposed
The best vendor demo looks linear: upload the RFQ, read attachments, search for similar offers, generate a price and produce a draft. The real process, however, is not a single block. Each step has sources, risks, responsibilities, observable quality and different stop conditions.
Before discussing software, I decompose the process. In one sub-process AI can retrieve history and summarise; in another it can flag differences; in another it must stop. This is the difference between automating a demo and governing a business process.
Table 3 — Quote-to-order decomposition and AI role
Sub-process | Allowed AI role | Responsibility that remains human |
RFQ and attachment reading | Extract requirements, ambiguities and documentary sources. | Validate ambiguities and ask the client for clarifications. |
Historical offer search | Propose similar cases with cited technical differences. | Decide whether the case is truly comparable. |
Drawing and revision check | Flag differences, missing elements and tolerance risks. | Approve technical interpretation and stop critical cases. |
Cost and margin support | Prepare the dossier and scenario inputs. | Decide price, margin, conditions and exceptions. |
Offer draft | Draft language, clauses and assumptions. | Approve wording, liability and client communication. |
Release and handover | Create traceable dossier and handover notes. | Authorise offer release and order transition. |
4. AI governance architecture: ERP, CRM and PDM remain systems of record
In the pilot I do not allow AI to become the system of record. ERP, CRM and PDM/PLM remain authoritative; AI works in a controlled space, reads only what it is authorised to read, cites sources, produces dossiers and always passes through human approval.
This architecture is not designed to complicate the project. It is designed to prevent an apparent success from destroying auditability, permissions, data quality and responsibility. If the model makes a mistake, I must know why; if the vendor changes the model, I must measure the effect; if the company wants to exit, it must be able to export data, rules and logs.
5. AI Act, privacy, cybersecurity and standards: gates before the pilot
In the Alpina case, the decisive meeting is not with the vendor but with the CEO, CFO, IT/CISO, legal, procurement, HR and process owners. I do not replace lawyers, DPOs, CISOs or labour consultants. My work is to surface early which technical choices become regulatory, organisational and contractual choices.
The EU AI Act, the Italian AI law where applicable, GDPR, NIS2 when in scope, client policies, ISO 9001 already present in the company, ISO/IEC 27001 for information security, ISO/IEC 42001 as an AI management reference, the NIST AI Risk Management Framework and the NIST Cybersecurity Framework become operational questions: who is the deployer, which data enter the system, which logs are required, which uses are forbidden, which human oversight is necessary, how an incident is managed and which vendor contract can withstand an audit.
In the simulated perimeter, the system does not hire, dismiss, evaluate workers or decide automatically about people. I therefore do not treat it as high-risk by default. I do, however, record prohibited uses, reclassification conditions and thresholds that require formal involvement of the DPO, legal, HR or CISO.
Table 4 — Compliance and security gates in the simulated case
Area | Management question | Operational decision |
AI Act / Italian AI law | What is the intended use? Who is deployer? Which uses are prohibited or require reclassification? | Intended-use register, human oversight, internal transparency, logs and escalation conditions. |
GDPR / DPO | Which personal data, client notes or commercial data enter the system? | Minimisation, roles, retention, vendor DPA and DPIA if risk requires it. |
Cybersecurity / CISO | Which systems are connected and with which permissions? | Read-only pilot, least privilege, segregation, logging, incident path and security test before scale. |
Client and contractual constraints | Which client policies, export limits or confidentiality clauses apply? | Vendor clauses, audit rights, data location, subcontractor visibility and exit conditions. |
Standards and internal systems | Which standards already govern the company? | ISO 9001, security controls, AI management references and operational procedures mapped into the pilot. |
6. Multi-vendor and AI model lifecycle: avoiding lock-in and dependency
A central risk is dependency. In a real project it is not enough to ask the vendor for a powerful platform. I must ask how the company exits the vendor, how it replaces a model, how it exports data and configurations, how it governs deprecations, price increases, geopolitical tension and changes in service quality.
The solution is not to multiply suppliers without discipline. It is to separate the layers: systems of record, data layer, orchestration, model, application, integration, security and human control. If everything belongs to the same provider, the demo is simpler but the company is more fragile.
An AI model is not a machine tool that remains stable for ten years. It changes version, cost, policy, context window, regional availability, behaviour on long documents and security level. For this reason I introduce a Model Lifecycle Board: IT/CISO, process owner, senior technician, sales, controller and vendor. Every model change goes through a regression pack of historical RFQs, borderline cases, critical errors and margin controls.
Table 5 — Multi-vendor, continuity and model lifecycle
Layer | Risk if not governed | Condition required before scale |
ERP / CRM / PDM | The AI vendor becomes the system of record. | Read-only pilot; write-back only after approval; core systems remain authoritative. |
Knowledge base / RAG | Non-exportable index and lock-in on documents. | Exportable documents, metadata, rules and logs in readable format. |
Model provider | Model deprecation, policy change, price increase or regional restriction. | Replaceable model layer, regression pack and fallback. |
Integrator | Customisations become undocumented dependency. | Technical documentation, handover, test scripts and maintainability. |
Geopolitical exposure | Continuity and quality can be affected by sanctions, export restrictions or service geography. | Supplier map, data location, contractual remedies and alternative route. |
Lifecycle governance | Model upgrade improves demo but worsens critical cases. | Model Lifecycle Board and before/after evaluation on historical RFQs. |
7. AI managerial coaching: decision capital remains inside the company
This is where a part of my work enters that should not be confused with generic training. During the project I coach the CEO and management because the company must not only approve an AI choice: it must understand it, challenge it, defend it and review it over time.
Coaching does not serve to make a recommendation approved. It serves to ensure that the board can formulate better questions even when the consultant is no longer in the room. I ask the CEO: “If tomorrow the model costs three times as much, which decision changes?” I ask the CFO: “Is this cost, investment, avoided risk or future capability?” I ask the CISO: “Which log do you need in order to trust without paralysing the process?” I ask the vendor: “Show me how Alpina exits from you, not only how it enters.”
These conversations produce decision capital. I do not automatically turn it into certified ROI or an intangible asset on the balance sheet. Part of it becomes documentation, policy, playbooks, training and procedures; part enters the income statement only if it reduces errors, rework, dependency, inefficiency or the cost of future decisions.
Table 6 — Management Autonomy Evidence: making decision capital observable
Indicator | Baseline | End of simulated pilot | Gate for broad scale |
Board decision memo completed without consultant | n.a. | 70% | ≥80% |
Critical vendor questions formulated by management | n.a. | 8/10 | ≥8/10 |
Model Lifecycle meeting led internally | n.a. | weak pass | full pass |
Cost per dossier explained by CFO without support | n.a. | partial | mandatory |
No-go case justified by the team without consultant | n.a. | 1 simulation | 2 simulations before broad scale |
8. HR, turnover and AI skills: reusable capability after the project
An AI project can fail even when it technically works if the know-how remains in the heads of two people. In Alpina, turnover is a concrete risk: a senior technician close to retirement, an experienced sales manager who knows undocumented exceptions, and an overloaded IT team.
For this reason I treat training, role redesign and capability reuse as part of the project, not as an appendix. I do not train everyone to write prompts. I build roles: process owner, technical AI key user, CFO owner of cost per dossier, IT owner of logs, HR owner of training, legal/procurement owner of vendor clauses.
The technology step-up also increases attractiveness. A company that uses AI in a governed way, with clear processes and internal skills, becomes more attractive for technical, data, operations and young management profiles. But attractiveness does not come from saying “we use AI”. It comes from showing that AI is embedded in a serious system of responsibility, learning and professional growth.
Table 7 — Skills, turnover and reusable assets
Organisational risk | Countermeasure | Capital that remains |
Technical turnover | Validated knowledge base, borderline cases and comparability rules. | Transferable technical memory. |
Dependence on consultant or vendor | Playbook, decision memo and vendor challenge checklist. | Negotiation and decision autonomy. |
Generic training | Role-based training on real process cases. | Operational skills, not only AI literacy. |
Loss of quality after scale | Model lifecycle board and regression pack. | Internal control routine. |
Next AI project | Reuse of KPIs, cost model, RFP, logs, policy and governance. | Accelerator for the second AI process. |
9. AI business case: full costs before benefits
Many AI business cases are fragile because they add up licences and development but forget management time, training, validation, cybersecurity, privacy, contracts, tokens, MLOps, change management, maintenance, model updates and human verification costs.
In the Alpina case, the CFO does not accept a business case built on saved hours. He is right. Saved hours are not automatic value: they become value only if they release sellable capacity, reduce overtime, protect margin, avoid rework, increase quality or reduce risk. Every benefit needs a mechanism, an owner, a denominator and a link to income statement or cash.
I therefore use two views: a complete cost vector, which prevents real costs from being hidden, and a CFO one-page view, which allows the board to understand in seconds whether the pilot produces evidence or only enthusiasm.
Table 8 — Complete AI cost vector for the Alpina pilot
Cost item | 12-week pilot | Annual run-rate after partial scale | CFO reading |
Strategic consulting, GDE and management coaching | €38–55k | €18–36k refresh/advisory | It serves to decide, not to create dependency. |
Application vendor and PoC | €28–55k | €45–80k licences/service | Must be tied to SLA, export and performance. |
ERP/CRM/PDM integration and data layer | €35–70k | €20–45k maintenance | Key cost to avoid isolated demos. |
Security, privacy, legal, procurement | €15–30k | €10–24k reviews and audits | Not bureaucracy: it reduces operational risk. |
Licences, tokens, vector DB, evaluation, logging | €9–22k | €32–70k variable by volume | Cost per dossier must be monitored monthly. |
Training, HR, management and key user time | €45–75k estimated internal cost | €25–55k refresh and onboarding | Often hidden; it affects adoption and autonomy. |
Scenario total | €170–307k | €150–310k | Does not authorise scale: it creates the evidence base. |
Table 9 — CFO one-page view
Block | Management reading |
Pilot | It must not promise immediate payback; it must produce evidence on process, data, cost per dossier, quality and responsibilities. |
Run-rate | Licences, tokens, MLOps, security, coaching refresh and internal owner are part of real cost. |
Gross benefit scenario | It matters only if it reduces rework, protects margin, increases sellable capacity or avoids observable risks. |
Net scenario impact | In the simulated case it becomes interesting only after stabilisation: annual gross benefit €230–410k minus run-rate €150–310k, strongly dependent on volumes and quality. |
Anti-overclaim | Saved hours, commercial satisfaction and a successful demo are not automatic value. |
Decision | Budget by tranches; scale only after proof gate, contract gate, security gate and management autonomy evidence. |
10. Causal AI pilot: a demo shows possibility, a pilot shows conditions
The pilot lasts twelve weeks. Two product families use Quote Copilot; two similar families remain AI-off. The system does not send offers and does not decide prices. Every dossier cites sources; every human change is tracked; every critical error enters the register.
Halfway through the pilot, sales is satisfied: “We are responding faster.” The technical manager is less convinced: “The system proposes historical cases that are similar by client, but not always by revision or tolerance.” The vendor defends the model: “We can improve with more data.” The CFO asks: “Yes, but how much does each corrected dossier cost?”
This is where orchestration matters. I do not allow an average improvement to hide a specific risk. The project does not fail; it becomes more governable. The vendor agrees to move part of the comparability logic out of the prompt and into controlled rules. The technical team defines the cases in which AI must stop. Management learns to distinguish a promising result from a scalable result.
Table 10 — Comparative pilot: evidence and limits
KPI | AI-off baseline | AI-on pilot | Prudent reading |
Average time for complex dossier | 7.8 days | 4.9 days | Improves, but must be separated by product family. |
Offer rework | 18% | 11% | Improves; verify that severe technical errors do not increase. |
Critical drawing revision errors | 3.1% | 2.7% | Improves little: does not authorise AI autonomy. |
Technical review time | 52 min | 61 min | Increases: the system shifts work, it does not eliminate it. |
Full cost per AI-on dossier | n.a. | €68–104 | Must be compared with margin, avoided rework and sellable capacity. |
Team ability to explain decision without consultant | n.a. | partial | Autonomy gate not yet full. |
11. Scale/no-scale: the value of consulting is visible also when I say no
At the end of the pilot, the board would like one sentence: “it works” or “it does not work”. I bring a more useful decision: it works on some product families, under constraints; it is not ready for general rollout; it can scale only after technical repair, security validation, contracts and skills consolidation.
My value is not visible only when I authorise scale. It is also visible when I reduce the perimeter, stop a claim, ask for an exit test from the vendor, separate a weak metric from real benefit, or prevent a promising pilot from becoming a general rollout without evidence.
A demo shows possibility. A pilot shows conditions. Only a measured process, with complete costs, defined responsibilities and passed gates, can authorise scale.
Table 11 — Final gate: scale/no-scale decision
Gate | State in the simulated case | Decision |
Data and integration | Partial pass: lineage and permissions improved, but not complete on all families. | Scale only on families with sufficient data readiness. |
Security and privacy | Conditional pass: logs, roles and segregation active; additional tests required. | Budget released only after security repair. |
Vendor contract | Exit clause and export accepted, but model quality SLA to strengthen. | No general rollout without contract gate. |
Economic value | Positive scenario benefit but sensitive to volumes, token cost and technical rework. | Next tranches linked to cost per dossier and protected margin. |
Management autonomy | Improving, but not full. | Second coaching round and two no-go simulations before broad scale. |
12. Client autonomy: AI consulting must be able to live without the consultant
I do not consider a project successful if the company has to call me for every ordinary decision. Valuable consulting does not replace management: it makes management stronger.
In the Alpina case, my exit objective is explicit: after stabilisation, the company must own process owners, an AI policy, vendor playbook, model lifecycle board, cost dashboard, knowledge base, training pack, standard decision memo and a clear list of cases in which to call me again.
The right relationship is not permanent dependency. It is growing autonomy with qualified re-entry when complexity exceeds internal capability or when management wants a second independent reading on a high-impact step: architecture change, new vendor, new regulation, dispute, international scale, major investment or performance crisis.
Table 12 — Client Autonomy Release Plan
What must remain in the company | Autonomy evidence | When it makes sense to call me again |
AI policy and Human-AI Authority Matrix | The board can explain what AI must not decide. | New high-risk use or responsibility change. |
Vendor playbook and exit test | Procurement and IT know how to ask for export, SLA, logs and rollback. | New tender, lock-in, vendor crisis or geopolitical tension. |
Model lifecycle board | The company evaluates a new version with regression pack. | Critical model change or performance drop. |
Cost dashboard | CFO explains cost per dossier and run-rate without support. | Economic deviations or scale decision. |
Training pack and knowledge base | Onboarding of a new key user without substantial loss. | Critical turnover or new AI process. |
Conclusion — AI consulting for companies: I do not sell AI to management
I do not sell AI to management. I build the conditions for management to decide whether, where, how and with whom to adopt it without losing control, margin, responsibility and autonomy.
The Alpina case shows why introducing AI into a company requires more than selecting a platform. It requires orchestration that holds together management, operations, IT, cyber, privacy, HR, internal standards, vendors, clients, geopolitics, costs, financial impact and the ability to learn.
Sometimes the best result is to start. Sometimes it is to reduce scope. Sometimes it is to stop a vendor claim. Sometimes it is to invest in data first. Sometimes it is to discover that value is not in the hours saved, but in the margin not lost, the risk avoided, the quality of the decision and the organisation’s ability to learn.
This is what the GDE applied to AI in business is for: to transform AI adoption from a technology purchase into a stronger managerial choice and a corporate capability that remains.
13. Quick questions on AI consulting, pilots and governance
Why does introducing AI into a company not equal choosing software?
Because value does not come from the platform itself, but from the process that is observed, measured, governed and connected to costs, responsibilities, data and human decisions.
What does a well-built AI pilot measure?
It measures conditions, limits and impact: dossier quality, critical errors, time, cost per dossier, avoided rework, margin protection, security, vendor governance and team autonomy.
Why must AI costs include tokens, training, cybersecurity and management time?
Because licences and development are only part of the real cost. Without tokens, MLOps, security, contracts, validation, training and management time, the business case is incomplete.
What is the role of managerial coaching in an AI project?
Coaching ensures that CEOs and management understand the choices, formulate better questions, recognise the limits of automation and can decide even when the consultant is no longer present.
When does it make sense to scale an AI project?
It makes sense only after proof gates: sufficient data, observable value, clear responsibilities, governed security and compliance, controlled costs, replaceable vendor and an internal team able to govern the model lifecycle.
Commenti