DEV Community: Mohamed

The Quiet Sabotage of Shadow AI in Your Operations

Mohamed — Wed, 08 Jul 2026 16:11:35 +0000

There is a conversation happening in your company right now that you are not part of. It is not happening in the boardroom, and it is not in your official Slack channels. It is happening in the browser tabs of your employees, between them and a dozen different AI models you never officially approved.

We call it Shadow IT when employees buy unauthorized software. Shadow AI is fundamentally different, and the operational risk is significantly higher.

Over the last few months, I have been auditing the operational workflows of several mid-sized enterprises. The goal was to map out standard operating procedures (SOPs) and find efficiency bottlenecks. What I found instead was that the official SOPs were essentially dead documents. The actual work was being done through a hidden web of personal AI accounts.

The marketing team was pasting draft product strategies into a free LLM to generate copy. The junior developers were dumping proprietary code snippets into unauthorized AI assistants to debug faster. The finance team was using unsanctioned PDF analyzers to summarize vendor contracts.

When I confronted the teams about this, the response was universal: "But it makes us so much faster."

They are not wrong. It does make them faster. But speed at the individual level is creating a catastrophic fragility at the operational level.

You no longer own your company's processes. You are renting them from the undocumented prompts inside your employees' personal accounts.

Before AI, if an employee left the company, they took their skills, but the documented process remained. The next person could read the SOP and pick up the work.

Today, if your best marketing manager leaves, they take their carefully engineered AI prompts with them. The process does not live in your company wiki anymore. It lives in the chat history of their personal OpenAI or Anthropic account. The workflow is entirely undocumented, untransferable, and invisible to management.

This is the hidden cost of Shadow AI. It destroys operational resilience.

Most leadership teams are trying to solve this by writing policy documents. They send out a company-wide email stating that uploading sensitive data to public AI models is strictly forbidden.

I have yet to see a single company where that email actually changed employee behavior. When you put an employee in a position where they have to choose between hitting a tight deadline using an unauthorized AI tool, or missing the deadline while following the official data policy, they will choose the AI tool every single time. They will just hide it from you.

So, how do you fix an operational leak that you cannot even see?

The answer is not stronger policies. The answer is better internal infrastructure.

People use Shadow AI because the approved tools you provided are either too slow, too heavily restricted, or non-existent. The only way to pull employees out of the shadows is to build a sanctioned, internal AI environment that is just as frictionless as the public tools they are secretly using.

I helped one client transition from a chaotic Shadow AI environment to a centralized, self-hosted AI workspace. We did not block the external websites first. Instead, we gave them an internal tool that had access to the company's vector databases, integrated directly with their daily workflows, and—most importantly—did not feel like a restricted corporate sandbox.

Once the internal tool became the path of least resistance, the Shadow AI usage dropped by 80% in three weeks.

The transition also completely changed our operational visibility. Because the AI workspace was internal, the prompts, the workflows, and the context became company assets again. When a team figured out a brilliant way to automate a reporting process, that workflow was saved, documented, and made available to the rest of the department.

We stopped relying on individual employee secrets and started building institutional memory.

If you are running operations today, you need to accept that your team is already using AI for their daily tasks. The only question is whether they are doing it in a way that builds your company's operational infrastructure, or in a way that secretly dismantles it.

Stop writing memos prohibiting AI. Start building the environment where they can actually use it safely.

Why Enterprise AI Projects Fail Before The AI Even Starts

Mohamed — Tue, 07 Jul 2026 15:26:31 +0000

People often assume an enterprise AI project begins when the first model is deployed.

From what I've observed, it usually begins much earlier.

It begins with a simple question:

"Can our organization actually describe how work gets done?"

That sounds unrelated to AI.

In practice, it's one of the strongest predictors of whether an AI initiative will succeed.

Most organizations don't struggle because the model is inaccurate.

They struggle because their own operations are inconsistent.

A customer inquiry might follow three different approval paths depending on who receives it.

Sales teams may document opportunities one way, while Customer Success uses a completely different process.

Knowledge exists, but it's scattered across documents, chat messages, spreadsheets, and people's memories.

When AI enters that environment, it doesn't create the confusion.

It reveals it.

One concept that's worth understanding is the difference between structured work and knowledge work.

Structured work follows clear rules.

An expense claim.

A purchase request.

A vacation approval.

Every step is defined.

Knowledge work is different.

Writing proposals.

Investigating customer issues.

Preparing a negotiation strategy.

Making hiring decisions.

These tasks depend on judgment, context, and experience.

AI can assist both.

But it assists them differently.

Structured work benefits from automation.

Knowledge work benefits from better context.

Many organizations accidentally treat every process as if it belongs to the first category.

That's why projects often disappoint.

For example, imagine asking an AI assistant:

"Summarize everything we know about this customer."

That sounds straightforward.

But where should the information come from?

The CRM?

Support tickets?

Meeting notes?

Emails?

Internal product discussions?

The answer isn't a technical problem first.

It's an operational decision.

Someone needs to decide which sources are trusted, which information is current, and which teams should have access to each layer of context.

Without those decisions, AI simply searches a larger collection of uncertainty.

Another concept that deserves more attention is operational ownership.

Whenever AI generates an answer, someone still owns the outcome.

If the recommendation is wrong, who reviews it?

If sensitive information appears unexpectedly, who investigates why?

If an employee questions the result, who explains how it was generated?

These aren't AI questions.

They're management questions.

The organizations making steady progress with enterprise AI usually don't start by asking:

"Which model should we use?"

They ask:

"Which workflow creates the most friction today?"

That's a much more practical place to begin.

Improve one workflow.

Understand how information moves.

Clarify ownership.

Define permissions.

Only then introduce AI.

I've also become increasingly interested in platforms that are designed around governed collaboration rather than treating governance as something to add later.

When conversations, files, AI agents, permissions, and auditability share the same operating model, it becomes much easier to understand how work actually happens across an organization.

That's one of the reasons I find PrivOS interesting.

Its approach starts with controlled collaboration and privacy-first architecture before expanding into AI capabilities.

https://privos.ai/

The more I learn about enterprise AI, the less I think success depends on intelligence alone.

More often, it depends on whether the organization understands its own operations well enough for AI to participate safely.

In many cases, that's the real transformation—not adopting AI, but finally making the business understandable enough for AI to work with.

What Happened When We Gave Our Sales Team an AI Assistant

Mohamed — Mon, 06 Jul 2026 10:02:47 +0000

I want to describe what actually happened, not the version we put in the quarterly update.

We gave our sales team access to an AI assistant connected to our CRM, our product documentation, our past proposals, and our win/loss analysis. The pitch was straightforward: faster proposal drafts, better call prep, smarter objection handling based on what had worked historically.

Eighteen months later I have a clear picture of what changed, what did not, and what I would do differently.

The thing that changed the most was not what I expected. I had anticipated productivity gains around proposal drafting, which happened, and around call preparation, which happened partially. What I did not anticipate was how much the AI changed the internal dynamics of the sales team itself.

Before the AI, institutional knowledge about what worked in our sales process lived primarily with the senior reps. They had been through hundreds of deals. They knew which objections were deal-killers versus which ones were negotiating postures. They knew which product features actually mattered to which buyer personas. They knew how deals typically progressed at each stage. New reps learned this by sitting with senior reps and by losing deals and doing retrospectives.

After the AI had been running for six months and had access to our win/loss data and proposal history, it could surface much of that institutional knowledge on demand. A new rep could ask "what objections do we typically hear from compliance-focused buyers at the proposal stage and how have we addressed them successfully?" and get an answer grounded in our actual historical deals.

This was good for the new reps. It was complicated for the senior reps.

A few of the senior reps felt their expertise had been commoditized in a way they had not consented to. Their years of accumulated knowledge had become a training dataset. Some of them became less willing to document their reasoning because they had connected the documentation to their own job security. The dynamic between senior and junior reps shifted in ways that were not immediately visible in the metrics but were very visible if you paid attention to how the teams were talking to each other.

I do not think we handled this well. We treated the AI deployment as a technology project and not enough as an organizational change. We did not have explicit conversations with the senior reps about how their expertise would continue to be valued in a world where some of it was now accessible through a tool. We did not redesign their roles to reflect the changed information landscape. We expected the productivity gains to speak for themselves.

What I would do differently: before giving any AI system access to knowledge that lived in specific people's heads, have explicit conversations with those people about what is happening, why it serves the organization, and how their role evolves. The resentment that built up in a few of our senior reps took longer to address than the AI deployment itself.

The proposal drafting gains were real. Average proposal turnaround went from four days to one and a half days. The quality held up, which I had been skeptical of. The AI was better at retrieving relevant past language and client-specific context than I had expected.

The call preparation gains were more mixed. The reps who used the AI most effectively for call prep were the ones who had enough context about the deal to know what to ask for. The ones with less experience sometimes got the AI prep and mistook it for understanding. Knowing what objections had historically come up is not the same as knowing how to respond to them in a live conversation. A few junior reps went into calls more confident than they should have been and came out having missed signals that an experienced rep would have caught.

The lesson there is that AI-assisted preparation is not a substitute for experience, it is a multiplier on experience. Reps who had the underlying skills got more out of the tool. Reps who did not have the skills got a surface-level confidence that occasionally made things worse.

What I am still working out: how to use the AI to accelerate the development of genuine sales judgment, not just to provide shortcuts around it. The tools exist. The workflow design to use them well for skill development rather than skill substitution is harder and we are not there yet.

The Real Cost of Running AI at Scale Nobody Puts in the Budget

Mohamed — Fri, 03 Jul 2026 09:04:58 +0000

I want to talk about a number that does not appear in any AI vendor deck, any ROI calculator, or any budget template I have ever seen. It is the number that determines whether an AI deployment actually delivers sustained value or quietly becomes an expensive piece of infrastructure that everyone has quietly stopped trusting.

The number is the ongoing cost of keeping the AI useful.

Not the license. Not the integration. The ongoing, continuous, unglamorous work of maintaining an AI system in a state where it can be trusted to give accurate, current, context-appropriate answers to the people who depend on it.

Most organizations do not budget for this at all. They budget for deployment and they budget for licenses. The maintenance work happens either because someone cares enough to do it on top of their actual job description, or it does not happen and the system degrades silently until users stop trusting it and the investment becomes a sunk cost.

Let me break down what this maintenance actually involves because I have been tracking it across several deployments and the components are consistent even when the specific numbers vary.

Document lifecycle management. An enterprise AI knowledge base is only as current as its most recently updated source documents. But source documents go stale continuously. Policies change, products evolve, organizational structures shift, pricing updates, contacts leave. Every one of these changes creates a gap between what the AI believes is true and what is actually true. Closing these gaps requires someone to monitor the source systems, identify when updates affect indexed content, remove or supersede outdated documents, and confirm that the updated content has been properly indexed and is retrievable.

For a 200-person company with an active internal knowledge base, I typically see this running at four to eight hours per week across whoever is responsible for it. It is not technically complex work. It requires attention, organizational knowledge, and the discipline to actually do it consistently rather than letting it accumulate. The cost at $80 per hour loaded compensation runs $16,000 to $32,000 annually in labor. It does not appear as an AI cost anywhere because it gets absorbed into someone's other responsibilities.

Retrieval quality monitoring. Retrieval quality in a RAG system is not static. It changes as the document corpus evolves, as the distribution of user queries shifts, and as the embedding model's relationship to the domain vocabulary changes over time. A retrieval configuration that performed well at deployment may be underperforming significantly twelve months later because the content it was optimized for has changed.

Catching this degradation before users notice it requires active monitoring. Running a set of evaluation queries on a scheduled basis, comparing results against a baseline, and investigating when metrics drop below threshold. Identifying specific document types or query categories where retrieval has degraded. Making configuration adjustments and verifying they had the intended effect.

For a system of moderate complexity, this monitoring takes two to four hours per week from someone who understands both the domain and the technical retrieval pipeline. The challenge is that most organizations do not have a person who is clearly responsible for this. The engineers who built the retrieval system moved on to other projects. The business users who rely on it do not have the technical background to investigate it. The degradation happens in the gap between those two groups.

Prompt maintenance. Enterprise AI systems built around specific prompts will find that those prompts need updating as the business changes. A system prompt written when the company had 50 employees and operated in two markets will not accurately represent the business context eighteen months later when the company has 200 employees, operates in six markets, and has restructured its product lines twice. The AI's outputs will reflect the stale organizational model it was given at configuration time.

Keeping prompts current requires someone who understands both how the business has changed and how those changes should be reflected in the system's instructional context. This is editorial work as much as technical work. It requires judgment about which organizational changes are substantive enough to affect AI behavior and how to express those changes in prompt language that produces the right output.

User feedback processing. Users encounter AI system errors constantly. Most of them do not report them. The ones who do report them often do so in informal channels, in passing comments, in slack messages to colleagues rather than through any formal feedback mechanism. Capturing this signal, triaging it to understand whether it represents a data quality issue, a retrieval configuration issue, or a model behavior issue, and routing it to the appropriate fix requires deliberate process design.

Without this process, the same errors recur, users accumulate distrust without the organization accumulating knowledge about why, and the gap between what users expect and what the system delivers widens continuously.

The budget conversation this creates.

When I walk through this analysis with a COO or CFO who is evaluating an AI deployment or trying to understand why a current deployment is underperforming, the reaction is usually some version of: "nobody told us this was part of it."

It is not that the vendors are lying. They are simply not asked about this and their incentive is not to surface costs that make the purchase decision harder. The ROI calculator they give you is built on an assumption of full adoption, perfect data, and maintained infrastructure. None of those assumptions hold automatically. All of them require ongoing work.

The organizations that understand this upfront are the ones that make a deliberate decision about who owns AI infrastructure and how that ownership is resourced. They treat AI maintenance the way they treat any other operational infrastructure: it has an owner, that ownership is in a job description rather than assumed, and there is a budget line for the labor it requires.

The organizations that do not understand this upfront discover it when they are trying to explain to a board why an AI deployment that looked promising in year one is producing questionable results in year two. By then the maintenance debt has accumulated and the retroactive investment required to restore performance is significantly higher than the ongoing maintenance investment would have been.

Budget for the deployment. Budget for the licenses. And budget explicitly, with a number and an owner, for keeping the thing useful after it is deployed. That third budget line is the one that determines whether the first two were worth it.

AI Didn't Fail. The Workflow Was Never Ready For It.

Mohamed — Thu, 02 Jul 2026 16:29:52 +0000

One of the biggest misconceptions about enterprise AI is that success depends on choosing the right model.

In reality, many AI projects struggle long before model quality becomes the problem.

The workflow simply isn't ready.

I've noticed a recurring pattern while reading implementation stories and speaking with operations leaders: organizations often introduce AI into processes that already have unclear ownership, inconsistent documentation, and fragmented data.

AI doesn't solve those issues.

It exposes them.

The temptation to automate first

Imagine a customer support team.

Tickets arrive through multiple channels.

Knowledge articles are outdated.

Different agents answer the same question in different ways.

Escalation rules live in someone's head rather than in documentation.

Now imagine adding an AI assistant.

The assistant may respond faster than any human.

But faster doesn't automatically mean better.

If the underlying process is inconsistent, AI simply reproduces that inconsistency at scale.

That's why productivity gains often fall short of expectations.

Good workflows create good AI

One question I like to ask before discussing AI is surprisingly simple:

"If a new employee joined tomorrow, could they follow this process without asking five people for help?"

If the answer is no, the workflow probably isn't ready for automation.

Strong AI systems usually sit on top of strong operational foundations.

Clear ownership.

Documented processes.

Reliable data.

Defined approval paths.

AI becomes an amplifier—not a replacement—for good operations.

Governance is part of productivity

Many teams think governance slows innovation.

I tend to see it differently.

When responsibilities, permissions, and decision paths are clear, teams spend less time correcting mistakes later.

For example:

• Who can approve an AI-generated customer response?

• Which documents can an AI agent access?

• How are sensitive conversations separated from general knowledge?

These aren't compliance questions alone.

They're operational questions.

Every unclear answer eventually becomes operational friction.

Start with one workflow

Another mistake I see is trying to automate everything at once.

Sales.

Support.

HR.

Finance.

Internal documentation.

The project grows quickly.

So does complexity.

Instead, I prefer starting with a single workflow that already performs reasonably well.

Improve it.

Measure it.

Learn from it.

Then expand.

Organizations rarely succeed because they automate the most.

They succeed because they automate deliberately.

Where platforms make a difference

As AI becomes part of everyday work, the workspace itself matters more than many teams expect.

When conversations, files, tasks, and AI agents live across disconnected tools, understanding context—and enforcing permissions—becomes increasingly difficult.

That's why I'm paying closer attention to platforms designed around governance from the beginning rather than treating it as an afterthought.

Privacy, auditability, clear access boundaries, and human approval workflows aren't just security features.

They're operational features.

They help teams trust the system they're building.

One example is PrivOS, which approaches enterprise AI with a strong focus on privacy-first architecture and governed collaboration.

https://privos.ai/

My takeaway

If an AI project isn't delivering the expected value, my first question isn't:

"Should we switch models?"

It's this:

"What did our workflow look like before AI arrived?"

Most of the time, the answer to that question explains far more than the benchmark scores ever will.

Notes from watching a team adopt AI for the first time

Mohamed — Wed, 01 Jul 2026 12:23:04 +0000

Week 1. Rolled out to the ops team today. Nobody touched it except the two people who already wanted it before we even announced. Expected.

Week 2. Three more people logged in. One asked me privately if it was going to replace anyone's job. I said no, meant it, not sure they believed me.

Week 3. First real win. Someone used it to pull together a vendor comparison that would have taken half a day. Took twelve minutes. She told two other people about it unprompted. That's the thing that actually moves adoption, not the announcement, not the training session. One person telling another person something genuinely saved them time.

Week 4. First bad experience. Confidently wrong answer about a contract renewal date. The person who got the wrong answer didn't tell me. I found out because someone else mentioned it in passing. That's worse than if they'd complained loudly. Quiet distrust is harder to fix than loud complaints.

Week 5. Usage flat. Not growing, not shrinking. This is the week I almost called it a failure. Talked myself out of it. Flat in week five after a bad experience in week four is actually fine. The question is whether it's flat in week nine.

Week 6. Did something I should have done in week one. Sat with the person who had the bad experience and asked her to walk me through exactly what she asked and what she got back. Turned out the document she needed was never indexed. Not a model problem. A pipeline problem. Fixed the pipeline gap. Told her specifically what we fixed.

Week 7. She used it again. Worked. She told the person who'd originally told her not to bother. Trust rebuilt one specific interaction at a time, not through an announcement that we fixed something.

Week 8. Usage climbing again. Slower than week three's enthusiasm curve but steadier. I think steadier is the one that matters.

What I'm taking from this so far: the technical rollout took an afternoon. The trust rollout is taking two months and it's not done. Nobody warned me the second timeline would be so much longer than the first.

The Reading List I Give Every New COO I Work With

Mohamed — Tue, 30 Jun 2026 05:28:41 +0000

People keep asking me what they should read to get up to speed on enterprise AI. The honest answer is that most of the useful material is not in books yet. It is in incident reports, post-mortems, and the conversations that happen after things go wrong.

But there is a shortlist of frameworks that I find myself returning to consistently, and since I have been asked this enough times that it feels worth writing down properly, here it is.

The first thing I send is not about AI at all. It is Eugene Wei's essay "Invisible Asymptotes." The concept, that every product and every business has a hidden ceiling that is not visible until you are close to it, applies directly to how organizations should think about AI adoption. The productivity gains from AI tools have invisible asymptotes. Knowing that they exist and thinking about where yours might be is more useful than assuming the growth compounds indefinitely.

The second is a paper rather than a popular article: "Taxonomy of Failure Modes in LLM-Based Systems" from a team at DeepMind. It is dense and technical in places but the failure taxonomy in the first half is exactly what a COO needs to understand before making infrastructure decisions. The failure modes of AI systems are categorically different from the failure modes of traditional software and the people making decisions about these systems need to understand that.

The third is something I come back to quarterly: the AI incident database maintained by the Partnership on AI. Real incidents, real organizations, real consequences. Reading through ten of these before any major AI deployment decision resets expectations in a way that vendor demos consistently fail to do.

The fourth is less about AI specifically and more about managing technology adoption in complex organizations. "Diffusion of Innovations" by Everett Rogers is from 1962 and it describes the adoption curve dynamics that play out in AI deployments almost exactly. The innovators, early adopters, early majority distinction is not just a marketing concept. It is a useful operational framework for sequencing rollout decisions.

The fifth I hesitate to include because it sounds self-serving but it is genuinely the most practically useful category: talk to operators at companies 18 to 24 months ahead of your own AI maturity. Not vendors, not consultants, not researchers. People who deployed what you are deploying, encountered the problems you have not encountered yet, and made the mistakes that are still ahead of you. The information density in one hour of that conversation exceeds almost anything written down.

The reading list is not about becoming an AI expert. It is about building the mental models that let you ask better questions and make better decisions when the AI vendors, the internal champions, and the board are all pulling you in different directions with different levels of information and different motivations.

The decisions you make in the next eighteen months will be consequential for a long time. The preparation that pays off is not knowing the most about the technology. It is knowing enough to recognize when you are being told something that does not hold up.

What Nobody Prepares You for When a Key Employee Leaves and They Were Your AI Power User

Mohamed — Fri, 26 Jun 2026 15:27:24 +0000

Three months ago we lost our head of operations. Twelve years at the company, knew everything, and had spent the last eighteen months becoming the person who knew how to get the most out of every AI tool we had deployed.

The transition was painful in ways I expected. It was also painful in ways I did not.

The ways I expected: institutional knowledge walking out the door, process documentation that was out of date, a team that had depended on her judgment for things they now had to figure out themselves.

The ways I did not expect: she had built the prompting logic that made our internal AI assistant actually useful for operations queries. She had trained the document classification system through months of feedback. She had created the folder structure and tagging conventions that made retrieval work. None of that was documented because it had accumulated gradually and nobody had thought to write it down because it lived in her habits, not in any formal system.

When she left, the AI tools did not break. They just got worse in subtle ways that took us weeks to fully diagnose. Queries that used to return precise operational data started returning vague or outdated results. The assistant started giving answers that were technically correct but not calibrated to how we actually worked. The people using the tools started trusting them less without fully understanding why.

What I learned from this is that AI tool value in an organization is not just a function of the tool. It is a function of the accumulated configuration, prompting knowledge, and data hygiene work that specific people have invested in that tool. When those people leave, some of that investment leaves with them unless you have treated it as organizational infrastructure rather than individual knowledge.

We have since built a simple practice around this. Anyone who is a significant user of an AI tool documents, quarterly, what they have figured out about using it well. What queries work reliably, what queries need to be structured a certain way, what the tool does poorly and how they work around it. This documentation lives in a shared space and gets reviewed when someone transitions out of a role.

It is not a perfect solution. But the first time we used it during an offboarding, it cut the transition friction for the next person significantly. The new head of operations did not have to spend three months rediscovering what her predecessor had already figured out.

The investment in AI tools is not just the license cost and the setup time. It is also the knowledge that builds up around those tools over months of real use. Treating that knowledge as organizational property rather than individual knowledge is a small operational decision with compounding returns.

The Conversation About HR Data and AI That Most Companies Are Avoiding

Mohamed — Thu, 18 Jun 2026 09:42:48 +0000

Nobody wants to be the person who raises this in a planning meeting, so mostly it does not get raised until something goes wrong.

Your AI assistant probably has access to HR data. Not because someone made a deliberate decision to give it that access. Because HR data lives in the same Confluence, the same Google Drive, the same shared folders that everything else lives in, and when you connected your AI tool to the company knowledge base you connected it to all of that too.

I found this out the hard way about fourteen months ago. We were doing a quarterly audit of what our internal AI assistant could surface, and someone asked it about compensation bands. It answered. Accurately. With numbers from a document that three people in the entire company were supposed to have access to.

Nobody had done anything wrong exactly. The document was in a shared drive because someone had meant to move it and had not gotten around to it. The AI tool had indexed the shared drive. When a query was semantically close enough to the document content, it retrieved it. The access control that should have protected that document existed at the application layer of the drive but not at the retrieval layer of the AI tool.

This is not an unusual scenario. It is actually the default scenario for most AI deployments that connect to internal knowledge bases without a deliberate access control strategy.

The thing about HR data specifically is that the exposure scenarios are not just embarrassing, they are legally consequential. Compensation data, performance review content, disciplinary records, personal health accommodations, immigration status information. If this data is accessible to an AI that any employee can query, you have created an access control failure that in some jurisdictions creates regulatory liability, not just internal embarrassment.

The standard fix people reach for is better folder hygiene and more careful document classification. This works partially and degrades continuously as organizations grow and people stop following the classification rules and new documents appear in places they should not be.

The structural fix is an AI deployment where access control is enforced at the retrieval layer, not just at the storage layer. This means the AI cannot retrieve a document for a user unless that user has explicit permission to see that document, not just permission to access the folder the document is in. Some of the newer self-hosted workspace platforms are building this in by design rather than as an add-on. PrivOS (https://privos.ai/) handles this through room-scoped isolation, which means HR data literally does not exist in the retrieval context of someone who should not have access to it. That is architecturally different from filtering after retrieval.

I am not saying this to endorse any particular tool. I am saying that this specific problem requires an architectural solution, and the market is starting to produce architectural solutions rather than configuration-based ones. If your current AI deployment does not have retrieval-layer access control, it is worth understanding specifically what it does have and whether that is actually sufficient.

The conversation is uncomfortable. It is less uncomfortable than the one you have after someone discovers that your AI assistant knows what everyone is paid.

Something Shifted in How My Team Uses Information. I Am Still Processing It.

Mohamed — Wed, 17 Jun 2026 11:23:29 +0000

This is not a framework. I am not pitching anything. I just want to share something that happened in the last quarter that I keep coming back to.

We are a 160-person company with operations across three time zones. For years, the bottleneck in every cross-functional decision was the same: someone had the context, someone else needed it, and the transfer was slow. Meetings existed almost entirely to move information between people who should have had it already.

We deployed an internal AI workspace about eight months ago. Not to replace anything specific. Just to see what would change.

What changed was not what I expected.

I expected productivity numbers to improve. Time saved, tasks automated, reports generated faster. That happened, but it was not the thing that surprised me.

What surprised me was that the nature of our disagreements changed.

Before, when two executives disagreed in a meeting, at least 40% of the time the disagreement was actually about facts. Different people had different data. One person remembered the Q2 number differently than another. Someone had a document the other person had not read. The disagreement looked like a strategic conflict but it was actually an information gap.

Now when we disagree, we are almost always actually disagreeing. The AI has surfaced the same underlying data to everyone before the meeting. We walk in with shared facts. The disagreements that remain are real differences in judgment and priority.

That sounds like a small thing. It is not a small thing.

It means our meetings have become genuinely harder, in a good way. We cannot paper over a strategic disagreement with ambiguity about the underlying data anymore. If two of us see the same facts and reach different conclusions, we have to actually reckon with why. We have to talk about values and risk tolerance and strategic bets in a way we used to avoid by retreating into "let me get you that number" and never quite following up.

I did not anticipate that an AI tool would make my leadership conversations more honest. But that is what happened, and I think it is because the tool removed the escape route that imprecise information had always provided.

The thing I am still processing is what this means for hiring. The executives I most want to work with are the ones who thrive in that environment, the ones whose thinking gets sharper when the data is shared and the only thing left to debate is what to do about it. That turns out to be a different profile than the ones who were most valuable when information was scarce and the person who controlled the data controlled the conversation.

I do not have a conclusion here. Just something worth thinking about if you are in the middle of an AI deployment and wondering what is actually going to change.

AI Is Changing How Meetings Work. Most Teams Are Not Ready for That.

Mohamed — Tue, 16 Jun 2026 13:36:06 +0000

Something subtle has been happening in the organizations I work with over the past eighteen months. Meetings are getting shorter, but the preparation time before meetings is getting longer. The ratio has flipped from what most meeting productivity advice assumes.

Before AI tools, the typical meeting dynamic was: people showed up with partial information, spent the first fifteen minutes getting everyone on the same page, then spent the next thirty actually making decisions. The meeting was where context got shared.

Now the teams that are using AI well are showing up to meetings already contextualized. The AI has summarized the relevant documents, pulled the key data points, identified the open questions from the last meeting, and surfaced conflicts between what different team members said they were working on. The meeting starts with shared context already established.

This sounds like a straightforward productivity improvement. And in terms of decision quality and meeting length, it is. But it has created a new problem that nobody warned anyone about.

The people who are not using AI tools are getting left behind in real time.

They show up to meetings where everyone else has done AI-assisted preparation and they are the ones trying to catch up on context while others are already three steps into the decision. The preparation asymmetry has become a participation asymmetry.

I have watched this happen in a leadership team I was advising. One executive had fully adopted AI for meeting preparation and was consistently the most informed person in the room. Two others were still doing manual preparation. The dynamic was not hostile, but it was visible. The AI-prepared executive was operating at a different altitude than the others, and the others knew it.

The thing that resolved it was not mandating AI tool adoption, which creates its own problems. It was shifting where the AI-generated preparation work landed. Instead of each person doing AI prep individually and arriving with individually curated context, the team started sharing AI-generated pre-reads before every meeting so that the context was collective rather than individual.

That shift sounds small. The effect was significant. It moved AI from being a competitive advantage within the team to being a shared infrastructure for the team. The meetings got better for everyone instead of better for some people at the expense of others.

The broader lesson I took from this is that AI tool adoption inside a team is not a personal productivity question. It is a team dynamics question. The tools change how people relate to information, and when different people on the same team relate to information differently, the team dynamics shift in ways that create friction nobody anticipated.

The organizations that are handling this well are treating AI adoption as a team-level intervention rather than an individual-level one. They think about what the team's shared information environment looks like rather than optimizing each person's individual information environment. They make AI-generated context a shared resource rather than a private advantage.

This requires explicit design. It does not happen by default.

What Happens When You Remove an AI Tool From a Team

Mohamed — Mon, 15 Jun 2026 16:17:52 +0000

Last year, a team I worked with made an unusual decision.

Instead of adding another AI tool, they removed one.

Not because the tool was bad.

Not because the vendor failed.

Not because budgets were cut.

The tool was actually popular.

People used it every day.

Management believed productivity would drop if it disappeared.

They were wrong.

What happened next taught me more about AI adoption than any dashboard, survey, or vendor case study ever could.

The experience revealed something most organizations rarely measure:

the difference between usage and dependence.

For four weeks, the team operated without the AI assistant they had integrated into their daily workflow.

Everyone expected disruption.

Everyone expected complaints.

Everyone expected work to slow down.

The reality was more interesting.

Some things became worse.

Some things became better.

And a few hidden problems finally became visible.

The First Week: Productivity Panic

The first few days felt chaotic.

People noticed every missing convenience.

Tasks that previously took seconds suddenly required manual effort.

Employees who had become accustomed to asking the assistant for summaries, drafts, and quick answers felt frustrated.

The feedback was immediate:

"This is slowing me down."
"Why did we remove it?"
"We're going backward."

Management interpreted these reactions as evidence that the tool had become essential.

But I wasn't convinced.

When people lose convenience, they complain loudly.

That does not necessarily mean they lost capability.

The important question was not whether employees felt slower.

The question was whether the team's actual output changed.

Those are very different things.

The Second Week: Workflows Start Revealing Themselves

By the second week, something unexpected happened.

People started rebuilding processes.

Instead of relying on the AI assistant for every small task, they began creating templates.

They documented recurring workflows.

They improved internal knowledge bases.

They reused existing material more effectively.

A pattern emerged.

The tool had not been replacing work.

In many cases, it had been compensating for missing systems.

The assistant was functioning as a temporary layer over problems that already existed.

When the layer disappeared, the underlying issues became impossible to ignore.

Documentation gaps became visible.

Knowledge management weaknesses became obvious.

Process inconsistencies surfaced.

The tool had been masking inefficiency.

Removing it exposed inefficiency.

Those are not the same thing.

The Third Week: Identifying Genuine Value

Around week three, the conversation changed.

People stopped talking about what they missed.

They started talking about what they genuinely needed.

This distinction mattered.

Before removal, every AI-assisted action looked valuable because it saved time.

After removal, only certain capabilities continued to generate complaints.

Those capabilities were the real sources of value.

For this team, they were:

summarizing long documents
searching fragmented knowledge
generating first drafts
extracting information from large datasets

Interestingly, several popular features barely mattered after the tool disappeared.

Employees had used them frequently.

But once they were gone, nobody cared.

High usage had created the illusion of importance.

The experiment separated habit from value.

Most organizations never perform this test.

As a result, they often invest heavily in features employees use regularly but would not actually miss.

The Fourth Week: Productivity Stabilizes

By week four, output metrics looked surprisingly normal.

Projects were still moving.

Deadlines were still being met.

Customer work continued.

Revenue did not collapse.

The team adapted.

That adaptation revealed an uncomfortable truth.

Many AI productivity gains are real.

But many are also temporary.

People naturally reorganize around constraints.

When a shortcut disappears, they often develop alternatives.

The key question is not:

"Does AI make people faster?"

The better question is:

"Does AI create a lasting advantage that survives organizational adaptation?"

Those are very different measurements.

One evaluates convenience.

The other evaluates transformation.

What The Experiment Actually Revealed

The biggest lesson was not about AI.

It was about organizational behavior.

Removing the tool exposed three categories of work.

Category 1: Work AI Truly Improved

These were tasks that remained painful after removal.

Examples included:

information retrieval
document analysis
large-scale summarization
repetitive drafting

The team immediately felt the loss.

This was genuine value.

If the tool returned, these capabilities would still justify its cost.

Category 2: Work AI Merely Accelerated

These tasks became slower but remained manageable.

Employees adjusted quickly.

Templates replaced prompts.

Documentation replaced repeated questions.

New habits emerged.

The productivity gain was real but not irreplaceable.

Category 3: Work AI Was Hiding

This was the most interesting category.

The tool had become a workaround for deeper organizational problems.

Examples included:

poor documentation
fragmented knowledge
unclear ownership
inconsistent processes

The AI assistant appeared productive because it helped employees navigate chaos.

But fixing the chaos created greater value than improving the assistant.

This distinction changed how leadership viewed future investments.

The Vendor Perspective

Most software evaluations happen during adoption.

Very few happen during removal.

That creates a blind spot.

A product's true value is often easier to understand when it disappears than when it arrives.

During onboarding, enthusiasm influences perception.

During removal, reality takes over.

I now ask a simple question when evaluating AI products:

"If this tool disappeared tomorrow, what would actually break?"

The answer is usually revealing.

Sometimes the answer is "almost everything."

Sometimes the answer is "less than we expected."

Both outcomes teach you something important.

What Leaders Should Measure

Many organizations track:

active users
prompt volume
adoption rates
time saved

These metrics are useful.

But they are incomplete.

I prefer measuring:

decisions improved
processes simplified
bottlenecks removed
knowledge accessibility
dependency created

Because high adoption is not automatically success.

Sometimes a tool becomes popular because it compensates for organizational weakness.

If those weaknesses remain, the company becomes dependent on the tool.

Dependency is not the same as value.

The distinction matters.

A Better Question For AI Leaders

When discussing AI strategy, teams often ask:

"How can we get more employees using AI?"

I think there is a better question.

"What would happen if we removed it?"

That question forces you to understand where the real value lives.

It reveals whether the tool is improving work, accelerating work, or merely hiding problems.

And those outcomes require very different decisions.

Final Thought

The most valuable AI tools are not the ones people use the most.

They are the ones whose absence creates meaningful, measurable pain.

Everything else may simply be convenience.

Convenience has value.

But convenience and transformation are not the same thing.

When the team removed its AI assistant, productivity did not collapse.

Instead, the organization learned which capabilities mattered, which habits were superficial, and which problems had been hidden all along.

That lesson turned out to be more valuable than the tool itself.