For two years I have argued that AI should not replace people. It should let humans and machines each do what they do best. Last month McKinsey made the same case. Here is that vision, applied to the discipline where it matters most and how we have turned it into working architecture for requirements work.
For the past two years I have often spoken about creating a symbiosis between humans and artificial intelligence (AI). I see this as a state where AI does not replace humans. Instead, AI and humans focus on their respective strengths and collaborate on tasks to achieve a better overall outcome. Put too much emphasis on either side, AI or humans, and adoption will not deliver on its promise.
Nowhere is that balance more important than in systems engineering. Requirements work sits at the heart of every complex infrastructure, building and energy project. Get it wrong, and the error compounds through design, build and handover. It is high-stakes, judgement-heavy work and at the same time it is full of repetitive, administrative tasks that consume the time of experts who should be doing something better.
Last month that balance vision became a central theme in McKinsey's report, "The Symbiotic Enterprise: How Cognitive and Physical AI Are Reinventing Enterprise Execution" (June 2026). It is the first report by a renowned organisation to focus on the balance vision. The publication is a good moment to share how we apply it: Not as a slogan, but as a set of design principles we refuse to violate.
Augmentation and symbiosis are both forms of collaboration: neither replaces the human. The difference is what you optimise. Augmentation keeps your process and roles fixed and drops AI in to speed up the existing job, like a chatbot next to the requirements manager or a summariser next to the contract reviewer. Symbiosis redesigns the process and re-allocates tasks to whoever (human or machine) is genuinely best at them. That re-partitioning is where the step-change comes from; assisting a fixed role can only take you so far.
The stats in the McKinsey report describe the current state well:
Systems engineering knows this pattern intimately. There is a second, quieter failure mode in our field: tools that work fine on their own but never talk to each other. Picture three colleagues in three separate rooms. One extracts requirements, one checks quality, one verifies evidence, and they slide Excel sheets under each other's doors. Each tool is locally useful. But nobody can answer the questions that span them: what does this change impact? What is missing? Where is the risk?
Very few organizations report meaningful P&L impact because most still embed AI within existing workflows. (McKinsey)
The alternative to the three rooms is one table with one whiteboard, where everyone writes their findings on the same requirement. Then you simply ask the board. That, in plain language, is what a symbiotic requirements workflow looks like. Everything technical underneath is just the machinery of that whiteboard.
Within the systems engineering workflow, redesigned human-AI collaboration is already producing results that augmentation cannot reach. Three examples from our own platform show the split.
Requirements extraction: from highlighter to reviewer
The old way: an engineer reads hundreds of pages of contracts and EMVI documents, highlighting and copying every requirement by hand. The redesigned way: AI performs the extraction. It pulls requirements, assumptions and obligations from the documents, assigns each a unique ID, title and source, and checks them against INCOSE guidelines. The human sets the strategy, resolves the ambiguities that need contract knowledge, and owns the final set. Days of searching compress into a review session, with traceability from every requirement back to its source.
Requirements quality: from sampling to full coverage
No human can hold thousands of requirements in mind at once to spot the contradictions and duplications between them. AI can. It analyses the entire set simultaneously, scores each requirement against INCOSE quality criteria and surfaces conflicts across the whole document. The human then does what only the human can: weigh which contradictions are real conflicts and which are intentional, which reformulations preserve contractual intent, which issues are worth the change. The AI finds; the engineer judges.
Verification: from document archaeology to compliance oversight
Specialised AI agents map evidence to requirements across extensive documentation, locate exactly where each piece of evidence lives, and score the strength of every link. The thresholds are phase-aware, because what counts as sufficient at design differs from handover. The human confirms or challenges the links, handles the cases flagged as needing clarification, and remains accountable for the verification register that goes to the client.
And then the question no single tool can answer
The real payoff comes when these steps write to the same shared model. Then you can ask: show me the requirements that are weakly formulated, AND have no evidence yet, AND are allocated to a critical system. That is one query on a coherent model, versus an afternoon of manual cross-referencing across three Excel exports. This is the whiteboard at work: each tool's findings make every other tool's findings more valuable.
Here is the part most AI vendors skip. "Human in the loop" is easy to claim and easy to fake. A confirmation dialog that everyone blind-clicks is not a loop, it is decoration. If you are serious about symbiosis, it must be structural. These are the principles we build by, and they are worth demanding from any AI you let near your requirements:
Nothing auto-applies. Every AI feature follows the same pattern: AI proposes, the human accepts or rejects per item, and only accepted results are written, with provenance, so you can always see which data came from which tool and which was edited by hand. Rejection is not silent either: dropped and rejected signals are shown as counters, never hidden. A partial analysis must never read as a complete one.
AI signals; it does not score. An AI that produces a confident "risk score: 7.4" is manufacturing precision it does not have. Our AI gives a category, an impact class and a one-line motivation, with an honest confidence level. Low-confidence signals are visually damped, not deleted. Pseudo-precision is how trust dies in an engineering organisation.
Every claim must be pointable. An AI finding must cite a literal quote from the requirement text or a concrete fact from the model. And that is enforced by the software, not merely requested in a prompt. Prompt instructions are requests; parser checks are guarantees.
Expect most requirements to yield nothing. A well-formulated requirement with a concrete limit, a norm reference and a verification method is, by default, not a problem. An AI tuned to always find something is not a safety net; it is a noise generator that trains engineers to ignore it. Silence on clean requirements is a feature.
Validate before you trust. Every AI capability is tested against a falsifiable set: expected outcomes written down before the run, including requirements that must come back clean. If a tool cannot pass a test it could have failed, its output is opinion, not analysis.
Why does this matter so much? Because clients, regulators and society require someone to own the outcome, be trusted with it, and answer for it. In infrastructure, building and energy, that is not an abstraction: a verification register carries contractual weight, a requirements baseline carries safety implications. No amount of model capability removes the need for a professional who signs off. It only makes that professional more valuable. Which is why symbiosis is the no-regrets strategy: if AI progress is gradual, you win on productivity today; if it is sudden, you are the organisation that already knows how to govern powerful AI within a regulated engineering discipline.
McKinsey frames the symbiotic enterprise along three dimensions. Translated to the requirements domain:
|
DIMENSION |
TRADITIONAL ENTERPRISE |
SYMBIOTIC ENTERPRISE |
|
Human role |
Manually extracting, checking and verifying, with AI assistance |
Setting the requirements strategy, exercising judgement, supervising AI-driven extraction, analysis and verification |
|
Organisation |
Fixed roles per lifecycle phase; tools and data in silos |
Engineers moving fluidly across the lifecycle; tools writing to one shared, coherent model |
|
Economics |
Headcount-driven: more requirements means more engineers |
Technology-intensive: capacity scales with the document set, cost follows usage |
The organisational row deserves emphasis, because it holds a second symbiosis: between the systems you already own. Most engineering organisations run a mix of MBSE tooling, Requirement management tools, spreadsheets and more. The wrong answer is rip-and-replace, migrating everything into yet another system that then owns your data.
Our answer is a reasoning layer. Picture three layers. At the bottom sits your existing tooling: it stays, it remains the source, and it remains yours. In the middle sits a layer that adds meaning without owning the data: one identity per requirement across systems, typed relations, a model that speaks the standard language of the discipline. On top sit the answers no single system can give: what does this change impact, what is missing, where is the risk. The arrows between the bottom and middle layers point both ways. That is the no-lock-in promise made visible. The model is a projection of your data, not a copy that holds it hostage. You can always leave.
One honest caveat: for a single user running a single tool for a single task, little changes. The value materialises where tools meet, which is exactly where the traditional workflow leaks time, consistency and traceability.
A. Start where the pain is measurable. Requirements work is unusually well-suited to a deliberate start: the bottlenecks are known (extraction time, review backlogs, verification pressure before handover) and the output is measurable. Pick one lifecycle step, redesign it around the human-AI split, and measure before and after.
B. Organisation before technology. Review your requirements process as it really runs, not as the handbook says. Design the new setup with a clear role split, and recognise that reviewing AI output well is a genuine skill: knowing when to trust a signal, when to challenge it, and when the AI's silence means clean rather than missed. The organisations that build that skill first will hold the advantage.
C. Measured and value-driven. Any AI initiative in the SE workflow must lead back to project goals: speed (shorter tender responses, earlier verification), quality (contradictions caught before design, full-coverage QA instead of sampling), risk and compliance (traceable registers, demonstrable INCOSE and ISO alignment, audit-ready evidence trails), and capacity (senior engineers freed for the judgement work only they can do). Balance initiatives along feasibility and value.
D. No rip-and-replace. Symbiosis does not require abandoning your requirements landscape. AI should slot into the workflow you have, importing from PDF and spreadsheets and exporting to spreadsheets, Semantic requirement models or online tooling and add coherence on top. Redesign the process, not necessarily the toolchain. Deliberately, nobody has to unlearn anything: the entry point looks like the spreadsheets workflow your team already knows. The difference is what happens in between. The question comes before the export, so you export the answer, not just the ingredients.
E. Choose future-proof technology. AI is moving incredibly fast, and there is increasing concern about data residency and AI legislation. That is acutely relevant when your documents are contracts for public infrastructure, and the EU AI Act comes into effect in August 2026. Avoid single-vendor lock-in, keep your requirements data exportable in open formats at all times, prefer platforms built to swap models as better options arrive, and choose vendors compliant with EU legislation and with your client contracts. The sector speaks standards, from INCOSE to ISO 15288, and audits demand traceability. Your AI layer should speak them too.
F. Build, fail and fix fast. Run a real project document through the chain of extraction, quality analysis and evidence-finding, and put the output in front of your engineers. Invite the sceptics: they find the issues that matter. Write down what you expect before you run, including what should come back clean. And agree a hard deadline by which the redesigned step must be live on a real project.
Basewise builds the reasoning layer for requirements work: AI for the people who write, analyse and verify requirements, across infra, building and energy. Tools in production today cover extraction from contracts and specifications, quality analysis against INCOSE criteria, evidence-finding for verification, and a knowledge chat grounded in your own project documents and standards. The shared model that connects them is in active development. Every capability follows the same non-negotiable: AI signals, humans decide. Nothing auto-applies, every finding is pointable to its source, and your data remains yours.
Our positioning in one line: no replacement, more impact per engineer.
The McKinsey report validates what we have been practising:
For engineering organisations, this moment is both opportunity and urgency. The requirements workflow is where AI symbiosis pays off first: the pain is measurable, the standards are codified, and the human judgement that remains is exactly the judgement your clients pay for. Organisations that wait for clarity will find themselves bidding against rivals who already deliver faster baselines, cleaner requirements and audit-ready verification at a structurally lower cost.
The question is not whether this transformation will reach systems engineering. It already has. The question is whether you will lead it or be disrupted by it.
The symbiotic systems engineer is not a future concept. It is emerging now, and the time to act is now.
Curious what this looks like on your own project documents? Request a demo at www.basewise.ai.