Why horizontal AI tools are not right for systems engineering

Every week we get the same question. We already have Microsoft Copilot (or ChatGPT, or Claude), so why would we not just configure our requirements extraction and review inside one of those? The short answer is no. Not if you care about accuracy, auditability, and data sovereignty.

In a real meeting we give more context, and that longer answer is what this piece is about. Horizontal AI tools, the general-purpose assistants designed to help everyone write emails, summarise meetings, and debug code, are fundamentally mismatched with the demands of systems engineering (SE). Even with custom prompts, plugins, and careful configuration, they hit a structural ceiling that vertical solutions like Basewise were specifically architected to break through.

A note before we start: this is not a jab at Copilot or any other generic assistant. They have their place and their purpose, one we cannot serve. This is a review of how different types of technology serve specific niches.

01 · The "jack of all trades" problem

General assistants need an exceptionally broad dataset to work, which is why the models that power Copilot are trained on data from the entire internet. As a result they know a little about everything and are an expert in none.

Models and control

Every frontier foundation model is trained as a generalist. Research from DeepMind and EPFL shows that multi-task fine-tuning inevitably creates constrained capacity and negative task interference: the same weights optimised for legal reasoning, creative writing, and open-ended conversation cannot simultaneously reach the depth required for safety-critical engineering standards.¹

We do not pretend to escape that foundation. We use the same base model family as Copilot, but that is where the similarity ends. Copilot is a one-size-fits-all consumer endpoint governed by Microsoft's backend routing, capacity management, and opaque parameter schedules. That stack is subject to change in context windows, model versions, token usage, and other parameters that shift the outputs without warning.

Basewise owns the full stack. We control the endpoints, the model variants, and the underlying inference parameters directly. That control means the behaviour of our system is deterministic and tuneable, not subject to the quality fluctuations that occur when a shared cloud backend throttles capacity or silently swaps model versions.

Inside that controlled environment we cage the generalist. Deterministic INCOSE guardrails execute before any token reaches the model. Project-specific retrieval grounds every response in your contract, standards, and verification history. Confidence scoring forces the system to declare uncertainty rather than hallucinate. And a narrow operational scope strips away everything except the reasoning required for the engineering task at hand.

So where Copilot gives you a raw generalist on a variable backend, Basewise gives you a specialised expert operating in a controlled environment.

Generic versus engineered outputs

In systems engineering, precision is non-negotiable. A requirement like "the system shall respond quickly to overcurrent conditions" is poorly written, unverifiable, untestable, and potentially contractually dangerous. Generic AI might flag it as "vague", but only a system trained on INCOSE and IEEE 29148 can explain why it is unverifiable, cite the specific rule (a missing measurable threshold), and propose a compliant rewrite. More than that, only an engineered system will deliver that analysis consistently and warn you when it hits ambiguity.

Gartner predicts that this kind of vertical specialisation will become central to using AI effectively in enterprise solutions, forecasting that 40 per cent of enterprise apps will feature task-specific AI agents by this year.²

02 · The compliance and auditability gap: Copilot cannot show its work

In regulated industries (healthcare, finance, insurance, and yes, large-scale infrastructure) every decision must be traceable years into the future. A system that cannot explain its determinations is not merely unhelpful. The lack of explainability is itself a compliance gap.

Microsoft Copilot's audit logs capture prompts and final responses, which delivers part of the required trail. But the log is not engineered to include the model's reasoning steps and intermediate data, and that is exactly the context you need if an audit asks why a requirement was approved.

For systems engineering this is a dealbreaker. INCOSE standards, ISO/IEC/IEEE 15288, and project-specific contractual frameworks all demand traceability. When Basewise's Requirements Quality Analyser (RQA) flags a requirement as ambiguous, it links to a specific rule code, shows the exact text that triggered the flag, and generates an audit-ready report. Every finding is explainable, and every decision is traceable.

Audit trails cannot be an afterthought. They are part of the architecture.

Our output is designed to withstand scrutiny from clients, regulators, and courts.

03 · Data sovereignty: the EU stack is non-negotiable

Here is something most enterprise AI buyers miss: running Copilot in Europe does not guarantee your data stays in Europe. Microsoft's own documentation acknowledges that Copilot may route requests to the primary tenant location, which means a European user's prompt could be processed in the United States if that is where the tenant home region is set. For infrastructure projects governed by GDPR, the EU AI Act, and national procurement law, that is unacceptable.

Even with multi-geo configurations, Copilot does not guarantee data processing in the same region as the user's mailbox or SharePoint site. And fundamentally you are still dependent on a US technology giant's infrastructure, subject to the CLOUD Act and to opaque subprocessors. This is not a matter of poor performance by Microsoft. It is simply the legislation the company is subject to.

Basewise made a deliberate, strategic decision: we are moving off the Microsoft stack entirely. We are in the middle of that transition, working to move our inference off hyperscaler stacks and onto a sovereign EU provider.

Soon we will operate on a fully data-sovereign EU stack, built on in-house technology with zero dependencies on large technology providers. Your data never leaves European jurisdiction. On many projects, that is a legal requirement.

04 · Hallucinations and confidence calibration

The most dangerous failure of all is AI's equal confidence whether it is right or wrong.

A June 2026 arXiv study analysing real court filings found over 1,000 cases containing AI-fabricated citations, with the number growing year on year.³ The Stanford HAI 2026 AI Index recorded sycophancy-induced hallucination rates of between 22 and 94 per cent across 26 frontier models on legal tasks.⁴

In systems engineering, a hallucinated regulatory claim or a fabricated verification standard can derail a €500 million infrastructure project, create legal claims, and even lead to dangerous situations.

Copilot has no built-in validation for regulatory accuracy. It does not know which version of a building code applies to your Dutch rail project. It cannot tell whether a verification method satisfies your specific EMVI contract. And when it is uncertain, it does not naturally flag that uncertainty. It guesses. Because of the underlying technology, even adding this context to a knowledge store does not guarantee the correct application.

Basewise addresses this with specialised retrieval engineering, structured reasoning, source citation, and confidence scoring. When our Requirements Evidence Finder (REF) cannot find sufficient proof for a requirement, it says so. When our apps are not sure about what they have found, they flag it and loop a human into the review.

The outputs are not obscure. They are an accurate reflection of the analysis, and they escalate to a human when needed.

05 · INCOSE compliance is not a prompt, it is an ontology

You cannot prompt your way to INCOSE compliance.

The INCOSE Guide to Writing Requirements, ISO 29148, and the SE Handbook represent a domain-specific ontology: a structured way of thinking about necessity, verifiability, consistency, and traceability that took decades and many experts to formalise.

Research comparing AI-assisted requirement evaluation with human expert assessment found that while AI tools "can provide consistent and rapid preliminary assessments, particularly for syntactic and structural quality attributes ... expert judgment remains essential for contextual interpretation, ambiguity resolution, and trade-off reasoning".⁵

The key is embedding that expert judgement into a multi-agent architecture, not asking a single general model to pretend it understands systems engineering. Basewise engineers the review process as a specialised framework that assigns tasks to specific models and trains agents for discrete functions:

one extracts requirements from contracts and standards;
another applies deterministic INCOSE rules;
a third performs semantic analysis for ambiguity and trade-offs;
and a fourth retrieves and scores evidence across project data.

Each agent operates within a narrow, governed scope with task-specific parameters, creating a system rather than a single agent performing a review.

Research into specialised industries supports the view that this gap cannot be bridged by better prompts. The structural mismatch between the operational design of general-purpose AI frameworks and the actual requirements of regulated industries is a mismatch by design.

06 · The market has already decided

The shift from horizontal to vertical for niche applications is neither new nor theoretical. There are already plenty of examples in the market. Gartner predicts the agentic AI market will reach $450 billion by 2035, with domain-specific implementations outpacing general-purpose deployments.²

Systems engineering is following the same trajectory. The question is not whether you will adopt AI for requirements management. It is whether you will adopt the tool built for your domain, or try to force a generalist to do a specialist's job.

07 · Basewise: AI built for systems engineering, by systems engineers

When we started Basewise we did not set out to build another chatbot. We set out to deliver a high-quality, reliable, purpose-built system that takes systems engineering to the next level. Basewise has to save engineers time, drive up the quality of projects, and embed systems engineering best practice in more of them.

Our current solutions target key stages of the SE journey:

DRE turns 500-page contracts into structured requirements tables in minutes.
RQA applies deterministic rules and LLM semantics to catch ambiguity, absolutes, and compound requirements, with INCOSE-compliant improvement proposals.
REF deploys three AI agents to find, assess, and score evidence for requirements, adapting to your project phase.
Knowledge Chat is your trained, SE-specific assistant, not a generalist pretending to understand your domain.
A fully data-sovereign EU stack: in-house technology, zero large-technology dependencies, GDPR and EU AI Act ready.

We have processed more than 50,000 requirements and performed more than 10,000 verifications. Our customers report time savings and quality improvements on every project they run.

08 · The bottom line

Keeping all of this in mind, here is the outcome. You can ask Copilot to review your requirements. You can write elaborate prompts about INCOSE standards to shape the output. You can assume your data stays in Europe and that the result is auditable.

But by design, generic horizontal assistants are not built to deliver the right outcome. Outputs will vary, change over time, and can be hard to explain. In the end that approach puts the SE process, and the projects that depend on it, at risk.

That is why you need AI built for SE from the ground up. That is Basewise.

09 · Sources

Karimi Mahabadi, R., Ruder, S., Dehghani, M. and Henderson, J. (2021) 'Parameter-efficient Multi-task Fine-tuning for Transformers via Shared Hypernetworks', arXiv preprint, arXiv:2106.04489. Available at: arxiv.org/abs/2106.04489 (Accessed: 2 July 2026).
Gartner (2025) 'Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026', Gartner Newsroom, 26 August. Available at: gartner.com.
Liu, Y., Stammbach, D. and Henderson, P. (2026) 'Who Checks the Citations? Benchmarking Legal Hallucination Detection', arXiv preprint, arXiv:2606.21155. Available at: arxiv.org/abs/2606.21155 (Accessed: 2 July 2026).
Stanford University Human-Centered Artificial Intelligence (2026) AI Index Report 2026. Stanford HAI. Available at: hai.stanford.edu/ai-index-report (Accessed: 2 July 2026).
arXiv (2026) 'AI-Assisted Requirements Engineering', arXiv preprint, arXiv:2604.15222. Available at: arxiv.org/abs/2604.15222 (Accessed: 2 July 2026).