By Head of Client Solution Design, Lionel Matsuya
If foundations set the purpose, and corridors shape the flow, wiring determines whether a house actually works in day-to-day life.
And just as modern homes are filled with smart devices, sensors and integrations, today’s GRC environments are increasingly wired with automation, clever logic and AI.
Here’s the central idea upfront:
Automation in GRC technology isn’t about throwing in every type of gimmick, but should be driven by business objectives and clear value-add for the team.
There are 2 perspectives to this:
- A general point: keep your strategic goals in mind during the design process, so you dictate what the technology delivers, not the technology dictating what your goals are.
- A specific point: don’t get swayed by an individual technology (like AI) which promises a lot but makes you change everything to meet its requirements.
When the “smart home” gets a little too smart
In a highly automated home, the lighting, blinds and heating all run through apps and connected systems. It’s something that’s very appealing to me personally – I get sold on the dream that everything is controllable with a tap on my phone (or a voice command).
It’s impressive, right up until a firmware update or network glitch means you need three steps, two apps and some luck to turn on a lamp. You end up spending much longer fixing the issue than you would just walking across the room and flicking a switch.
GRC implementations can end up the same.
Automations are added, conditions layered in, edge cases handled, data fields multiplied. While they make sense individually, collectively they create a structure that feels impressive, but is hard to explain and even harder to maintain.
It’s surprisingly common: what looked slick on day one requires specialist knowledge on day 100. A minor change becomes a mini project. A straightforward process becomes fragile because one dependency sits in the wrong place or the guy who knows how it all works isn’t around to help.
The real issue is this:
Every layer of automation is not just a feature: it’s a future responsibility.
If the system relies on the person who built it, or if the logic is so bespoke that no one can articulate it clearly, then the wiring isn’t enabling anything. It’s becoming a single point of failure.one can articulate it clearly, then the wiring isn’t enabling anything.
Reporting: where wiring most often gets distorted
Imagine rewiring your entire house so that every appliance can report hourly energy usage by room, season and device type – even though you only ever need the monthly bill.
This is what happens when reporting requirements expand unchecked.
Teams often generate long lists of metrics: detailed, highly specific, occasionally obscure.
And because they’re on the list, the system must produce them automatically – leading to:
- Data structures bent to accommodate edge case KPIscase KPIs
- Extra fields that complicate the model
- Fragile dependencies across modules
- Dashboards that need constant maintenance
- Resistance to change because the reports “might break”
The irony?
Many of these metrics could be generated in minutes using an export and a pivot.
The better question is usually:
“Are we redesigning our whole wiring to satisfy something that’s actually simple?”
Often, the answer is yes.
AI: the new wiring – powerful, helpful, but easy to misuse
I’ve been guilty of this more times than I’d care to admit: following a technology fad, but then frustrating my family with the implementation. Sometimes it’s worked well (home assistant devices with photos which you can voice control to set timers in the kitchen – success!), and sometimes it’s not worked so well (mesh wifi which makes the network slower – failure, though I’m not pinning the blame on the mesh wifi necessarily; it may have been poor implementation by me).
AI in GRC follows the same rule.
Used well, it provides genuinely useful support, like in CoreStream GRC, where AI can suggest controls when a risk is created, challenge vague wording, or help keep information consistent. It augments judgement, rather than replacing it.
Used poorly, AI becomes another shiny system dependency:
- Added because it feels modern
- Becomes its own process rather than fitting in with your workflow
- Hard to govern or validate
- Dubious gains
AI must serve the architecture, not dictate it.
Five questions that lead to cleaner, more resilient wiring
Whether you’re designing a new solution or reviewing an existing one, these questions cut through the noise:
1. What problem does this automation really solve?
If the answer is convenience rather than clarity or control, it might not be worth wiring in.
2. What’s the long-term cost of maintaining this particular added feature? term cost of maintaining it?
Most wiring doesn’t break immediately. It breaks when you need it most.
3. Who actually understands the logic of this “smart” element?
If the answer is “one person”, you’ve created fragility, not efficiency. Here at CoreStream GRC, we believe technology should be an enabler not a barrier, and so we’re passionate about designing environments that empower users with minimal training needed (if at all).
4. Is the design bending to fit the technology?
Technology should reflect the governance model, not the other way around.
5. Does this add-on make things clearer – or more opaque?
If no one can explain it confidently, it’s already a risk.
The takeaway
A well-wired GRC house doesn’t draw attention to itself. It quietly:
- Supports the flow of information
- Keeps reporting grounded in purpose, not volume
- Uses AI sensibly and transparently
- Stays adaptable
- Avoids single-point dependencies
- Gives people confidence, not confusion
The goal isn’t to build the most sophisticated wiring system imaginable. It’s to build one that will keep the lights on – reliably, predictably and without drama -when the pressure is on.
Next, I’ll be talking about the importance of the user experience – the subtle improvements that can lead to big GRC outcomes.
Check out Lionel’s previous blogs here
Designing your dream GRC home, part 1: the foundations of good GRC design
Designing your dream GRC home, part 2: connectivity and why corridors need to be planned
Designing your dream GRC home part 3: security and access
About Lionel Matsuya
Lionel is the Head of Client Solution Design at CoreStream GRC, where he’s disrupting the traditional approach to Governance, Risk, and Compliance. With 12 years of experience from a Big Four consulting firm, Lionel is all about designing bold, customized solutions that make clients rethink what’s possible with the CoreStream GRC platform. Lionel’s experience spans organizations of all sizes and across various levels of GRC maturity, both locally and globally. A chartered accountant with the ICAEW and a Certified Information Systems Auditor, Lionel is passionate about using technology to make people’s lives easier.
Connect with Lionel on LinkedIn here.
Frequently asked questions
Automation should solve a meaningful problem, improving clarity, control, or reducing genuine workload, not just adding convenience or novelty. If the benefit is marginal or the logic becomes hard to understand, it’s likely not worth wiring in.
Over‑automation often creates a fragile environment that depends on one specialist or a chain of overly complex logic. When a small change becomes a mini‑project, or no one can explain how things work, you’ve created a single point of failure instead of efficiency.
When reporting expands without guardrails, teams often reshape the entire data model around edge‑case metrics. This leads to unnecessary fields, brittle dependencies, and dashboards that constantly need maintenance, all for insights that could often be generated manually in minutes.
AI should enhance judgment, not dictate architecture. It’s powerful when it supports workflows, suggesting controls, improving clarity, and ensuring consistency. It becomes harmful when it forces process changes, adds unnecessary dependency, or becomes a standalone “feature” without clear value.
