Case Study · Construction & Trades
AI Governance for a Western NC Remodeling Company
Leadership asked us to review their new AI workspace. What arrived in the next twenty-four hours changed the scope of that question significantly.
Industry
Residential Remodeling
Location
Western NC
Focus
AI Governance & Policy
Status
Ongoing
The situation
In spring 2026, a residential remodeling company in western North Carolina came to us with a straightforward request: help them put a safety policy in place for a new AI workspace they were rolling out. Leadership described it as isolated — manual uploads only, nothing connected to company systems. They wanted guardrails before anyone started using it.
Within twenty-four hours, a plan arrived from the outside AI consultants the company had also engaged. That plan proposed wiring the AI directly into three production systems: their construction project management platform, their CRM, and their accounting system.
What leadership thought it was approving and what was being built were two different things. Nobody was acting in bad faith. The consultants were doing what they were hired to do. Leadership had not seen the integration scope yet. And nobody owned the decision about whether those connections should exist at all.
That gap — between what leadership believed and what was being built — was the real problem. We stopped work there and figured out how to close it.
Gaps found in the original integration plan
A recommended privacy control the client's plan tier did not actually offer
Prompt injection risk rated too low for production system access
Connectors visible to every workspace member, not just named users
AI inheriting the full permissions of whoever authorized it
No process to revoke access when an employee leaves
Risk of combining three separate data sources in one AI context not addressed
What we did
Paused the integrations without killing them
We did not tell the consultants to stop. We put the mismatch in front of leadership in plain language and got everyone — leadership, consultants, and IT — on one call. The goal was not to assign blame. It was to make sure the people who owned the risk actually understood what they were approving.
Wrote an AI acceptable use SOP
Before any connector went live, we drafted a policy covering: SSO and MFA required for all AI access, prohibited data categories, connectors locked down by default, required human verification of AI output before acting on it, incident response steps, and signed user acknowledgment. It also happens to be exactly what a cyber insurer wants to see.
Reviewed the integration plan in detail
We went through the consultants' proposed connections line by line. Six meaningful gaps, listed at right. Some were fixable with configuration changes. One required a plan upgrade the client had not been told about. All of them needed a named leader to formally accept the remaining risk in writing before anything connected.
Built a connector approval framework
Instead of a blanket yes or no on AI integrations, we put a process in place: every connector needs a named business purpose, one at a time with its own review, read-only access first with minimum scopes, no delete access ever, any write access needs separate approval and testing, written conditions for each approval, and a named leader who signs off on residual risk.
How the framework held up
Over the next six months, four connector requests went through the review process. Here is what each one found.
Request 1
Code repository connector
The review found that company work product was sitting in vendor-controlled storage with no independent backup, that access was broader than the two repositories requested and limited only by an honor-system promise, and that a path existed for data to leak between connected systems. The connector was approved — but with written conditions — and the findings were explained in plain language for non-technical leadership so they could make an informed call.
Request 2
Self-hosted automation platform
The proposed platform had multiple critical vulnerabilities under active exploitation at the time of the request. We advised against deployment until the vendor addressed those conditions. No guesswork required — the finding was documented and the decision was leadership's to make with full information.
Request 3
Microsoft 365 connector for a research project
This one came with conditions: access review first, read-only access only, email and Teams explicitly excluded. The access review is where things got interesting.
What the access review found
A project site accidentally shared with the entire company. More than a dozen "anyone with the link can edit" links on an external sharing site, including one link that had been opened by an unrecognized personal email account — escalated immediately to leadership.
The lesson here: an AI connector can reach everything the authorized user can reach. Years of forgotten oversharing become instantly findable. You clean up access before connecting the AI, not after. This is one reason the framework requires an access review as a precondition for every Microsoft 365 connector.
Request 4
Second AI platform, justified as "for modern work"
The request arrived with no business justification beyond the phrase "for modern work." We held it for leadership with three questions: is this a company plan or a personal account, what data does it need to reach, and what does it do that the approved platform does not. The framework is also a front door. Requests that cannot answer basic questions do not move forward until they can.
The control that proved itself
The Microsoft 365 connector was locked at the sign-in level to the one approved user. Weeks later, a second employee tried to connect and was blocked. He was told to try a different app. The block was the control working as designed. He was routed to the approval process instead of around it. That is what a functional policy looks like in practice.
What this means for your business
AI adoption usually starts before anyone tells IT
Expect it. Build a front door for it. A clear approval process keeps people inside the system instead of routing around it on personal accounts.
The right first question is not "Is the AI safe?"
Ask what it can reach. An AI tool is only as trustworthy as the data it has access to and the permissions of the person who authorized it.
Leadership owns the risk decision
IT's job is to make that decision informed. The policy, the access review, the written conditions — all of it exists so the person signing off actually understands what they are signing off on.
"Yes, with conditions" is better than "No"
A flat no sends people to their personal accounts, where there is no policy, no review, and no visibility. A conditional yes keeps the work inside a process you can audit.
Write it down
Policy, conditions, sign-offs. That record protects the company if something goes wrong, and it is exactly what a cyber insurer wants to see.
AI is a tool, not a strategy
Avoiding it is not a plan, and neither is connecting it to everything. The goal is deliberate adoption — one connector at a time, with someone's name on every decision.
Is your business ready for AI integrations?
An AI readiness review covers three things: an access audit of what the AI would actually be able to reach, a use policy your team will sign and follow, and a connector approval process that keeps adoption inside a system you control. We offer this as a standalone engagement.
Schedule a Free ConsultationRelated services
Cybersecurity & Endpoint Protection
Layered protection that covers endpoints, email threats, and now AI attack surface.
Microsoft 365 Administration
Governance, access controls, and ongoing tenant hygiene — including AI connector management.
Managed IT Support
Ongoing IT oversight so new tools — including AI — go through a process, not around one.