Lessons From 27+ Years in Technology - Part 2 of 3

The Technology Changed. The Need to Keep Learning Didn't.

In Part 1, I talked about starting my career as a carpenter building houses in the Washington, D.C. area while going to school and trying to find my way into technology.

Eventually, I got my opportunity as a Web Developer during the dot-com boom and Y2K era.

That was more than 27 years ago.

A lot has changed since then.

I've watched technologies that were once considered cutting-edge become obsolete. I've watched development languages and frameworks come and go. I've watched infrastructure move from physical servers to virtualization and the cloud. I've watched software evolve into SaaS platforms, mobile become part of everyday life, automation change business processes, and now artificial intelligence begin changing how we work again.

Every one of those changes required learning something new.

And I'm still learning today.

I use AI regularly. I'm interested in what it can do, where it can improve productivity, and how it can change the way we develop products and solve business problems.

But experience has also taught me not to confuse new with better.

That's an important distinction.

After enough years in technology, you start recognizing patterns.

I've seen organizations automate bad processes instead of asking whether the process itself should exist.

I've seen teams repeatedly fix symptoms because nobody had the time, authority, or inclination to find the root cause.

I've seen technical shortcuts that saved a few days eventually cost months.

I've seen organizations choose technology first and then try to figure out what business problem it was supposed to solve.

The names of the technologies change, but many of the underlying problems don't.

That's where I believe experience becomes particularly valuable.

Experience doesn't mean walking into a room already knowing the answer.

If anything, experience has taught me to be more comfortable saying, "I don't know. Let's figure it out."

But it has also taught me which questions we should probably ask before we start looking for the answer.

What problem are we actually trying to solve?

Why are we doing this?

Who does it help?

Are we fixing the root cause or another symptom?

Are we making something better, or simply making it newer?

And increasingly today: Are we using AI because it genuinely improves the outcome, or because AI happens to be the technology everyone is talking about?

Those questions aren't anti-technology.

They're exactly the opposite.

Technology is incredibly powerful when we apply it to the right problems.

I've spent more than 27 years watching the tools change, and I expect they'll continue changing faster than ever.

I'm not an expert in every new programming language, platform, framework, or AI tool that appears.

I don't need to pretend that I am.

What I do need to do is remain curious enough to learn, experienced enough to ask questions, and humble enough to surround myself with people who know things I don't.

Because after all these years, one lesson has remained remarkably consistent:

The best technology professionals aren't the people who already know everything. They're the people who never stop learning.

In Part 3, I'll talk about another change that happened along the way.

At some point, my career became less about the things I could personally build and more about the people I could help build them.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Stop Calling Every Old System "Legacy"

There’s a word in technology that I think we use far too casually: legacy. A system has been around for ten years? Legacy. It uses an older programming language? Legacy. The interface looks dated? Definitely legacy. Someone joins the company, sees technology they wouldn’t choose if they were starting today, and suddenly the conversation becomes, “We need to replace this.”

Maybe we do. But I think we need to be careful about confusing old technology with unhealthy technology. They aren't necessarily the same thing.

Old Doesn't Automatically Mean Broken

I've worked around technology long enough to remember plenty of platforms, programming languages, databases, operating systems, and architectural approaches that were once considered modern. Eventually, everything becomes old. That doesn't mean it stops working.

There are systems running businesses today that have been operating successfully for ten, fifteen, twenty years or longer. They process transactions, manage customers, handle complex business rules, integrate with other platforms, and generate revenue every single day. Some of them aren't pretty, and some certainly need modernization, but age alone isn't a business case for replacement.

The question shouldn't be “How old is it?” The question should be “Is it preventing us from going where we need to go?”

Sometimes Old Software Is Old Because It Works

Software that has survived for fifteen years has probably encountered an enormous number of real-world situations. Customers found edge cases. Developers fixed bugs. Business rules changed. Regulations changed. Integrations evolved. Production failures taught the organization lessons.

Multiply that by thousands of changes over many years and something interesting happens. The old system becomes more than source code. It becomes a record of what the business has learned.

The problem is that much of that knowledge may never have made it into formal documentation. It's simply in the software.

The Ugly Code Might Be Trying to Tell You Something

Every experienced developer has opened a piece of code and wondered, “Why on earth did somebody do it this way?” Sometimes the answer really is poor design. But sometimes there was a very good reason.

Maybe a major customer required something unusual. Maybe an external system behaved differently ten years ago. Maybe there was a regulatory requirement. Maybe someone discovered a production edge case at 2:00 in the morning and fixed something that prevented a serious business problem.

Years later, the comment is gone. The developer is gone. The ticket may be gone. The code remains.

That's why I get nervous when someone looks at an established platform and immediately concludes, “This is terrible. Let's rewrite it.” Before removing something we don't understand, perhaps the first question should be: “Why is it here?”

Modern Technology Can Still Produce Bad Software

We sometimes assume that replacing an older platform with modern technology automatically creates a better product. It doesn't.

You can build an unmaintainable system using the newest framework available. You can create poor architecture in the cloud. You can build technical debt with microservices. You can automate a bad process. You can create an elegant new user interface sitting on top of poorly understood business logic.

Modern tools give us tremendous capabilities, but technology doesn't compensate for weak product governance, poor architecture, inadequate testing, unclear ownership, or constantly changing priorities. A new technology stack placed inside an unhealthy development organization will eventually become somebody else's legacy platform.

So What Actually Makes a System “Legacy”?

For me, the more useful definition has very little to do with age. I'd start looking seriously at modernization when the platform is creating measurable constraints on the business.

Maybe the technology is no longer supported. Maybe security risks can no longer be reasonably mitigated. Maybe finding people who understand the technology has become increasingly difficult. Maybe integrations with modern systems are becoming impractical. Maybe the architecture prevents the company from scaling. Maybe development velocity has deteriorated to the point where meaningful product changes take far too long. Maybe operating the platform costs significantly more than a modern alternative would.

Those are business problems. “It's old” isn't.

Modernization Doesn't Have to Mean Replacement

The choice doesn't always have to be “keep everything exactly as it is” or “throw everything away and start over.” There's a lot of territory between those two extremes.

You can replace individual components, refactor high-risk areas, introduce APIs around older functionality, improve automated testing, modernize deployment processes, move appropriate workloads to newer infrastructure, improve monitoring, or gradually separate parts of a tightly coupled application.

In other words, modernize intentionally instead of replacing emotionally.

That approach isn't as exciting as announcing a completely new platform, but it can be dramatically less risky.

The Rewrite Has Its Own Technical Debt

One of the ironies of replacing an established system is that the new platform starts accumulating technical debt almost immediately. Requirements change while you're building it. Customers still need features. Business priorities change. Developers make compromises to hit deadlines.

Meanwhile, you're maintaining the existing platform and building its replacement. Now you have two systems, two sets of problems, and potentially two engineering efforts competing for resources.

This doesn't mean rewrites should never happen. Sometimes they absolutely should. It means the decision needs to be based on business constraints and technical evidence rather than frustration with the age of the existing system.

Respect the Knowledge Before You Replace the Technology

I've spent enough years in technology to appreciate new tools. I've also spent enough years in technology to respect old ones.

Before replacing an established system, understand it. Document it. Identify the business rules buried inside it. Understand the integrations. Find the edge cases. Talk to the people who have supported it. Figure out which problems actually come from the technology and which come from the processes surrounding it.

Then decide what needs to change.

Sometimes modernization means building something new. Sometimes it means replacing part of what already exists. And sometimes the smartest decision is improving the system you already have.

Old Isn't the Enemy

Technology should evolve. Platforms should improve. Organizations should continuously modernize. But modernization should have a purpose.

We shouldn't replace systems simply because they're old any more than we should keep them simply because they've always worked. Both can be emotional decisions.

The better question is: “What is preventing this platform from supporting where the business needs to go next?”

If the answer is the technology, modernize it. If the answer is architecture, address the architecture. If the answer is process, fix the process. If the answer is governance, improve governance.

And if the system is still reliable, supportable, secure, scalable, and capable of evolving, maybe calling it “legacy” says more about our perception of the technology than the actual health of the product.

Old software isn't necessarily technical debt. Sometimes it's simply software that survived.

This follows the principle in your original presentation that mature organizations use incremental modernization and targeted refactoring rather than assuming an aging platform automatically requires wholesale replacement.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Lessons From 27+ Years in Technology - Part 1 of 3

From Building Houses to Building Technology

I've spent more than 27 years working in technology, and when I look back at where it all started, I'm sometimes amazed at the path that got me here.

My career didn't actually begin in technology. Before I ever wrote code professionally, I was a carpenter building houses in the Washington, D.C. area.

At the same time, I was going to school because I wanted to break into this growing technology industry. I didn't have decades of experience. I didn't have a long list of certifications. I certainly didn't know where the career would eventually take me.

What I had was a willingness to learn, a positive attitude, and the determination to keep pushing forward until someone gave me an opportunity.

Eventually, someone did.

I started working as a Web Developer in the Washington, D.C. area, and it was quite a time to enter the industry. The dot-com boom was underway, businesses were racing to understand this relatively new thing called the Internet, and the world was preparing for Y2K.

Technology was changing incredibly quickly.

Looking back, though, one thing stands out to me about entering the industry during that time.

You weren't necessarily expected to know everything before someone was willing to give you an opportunity.

You needed some skills, of course. But you also needed the ability to learn, the willingness to work, and the persistence to figure things out when you didn't know the answer.

That last part became far more important to my career than I realized at the time.

Technology has a funny way of making today's expertise temporary. Eventually, the language changes. The platform changes. The hardware changes. The methodology changes. Something new comes along and suddenly everyone has something else to learn.

If your entire value is based on knowing a particular technology, eventually that technology is probably going to change.

But knowing how to learn, how to solve problems, and how to keep moving forward when you don't immediately know the answer has a much longer shelf life.

The carpenter who was building houses during the day while trying to find his way into technology couldn't possibly have known what the next 27+ years would bring.

I didn't know that I would eventually work across different industries, technologies, products, and leadership roles. I didn't know how many talented people I would have the opportunity to work with, learn from, mentor, lead, and eventually call friends.

I certainly couldn't have imagined cloud computing, SaaS, modern mobile technology, or artificial intelligence as we know them today.

I was simply trying to get my foot in the door.

Someone eventually opened that door.

The rest was up to me.

More than 27 years later, I think there's still an important lesson in that.

Sometimes potential isn't about everything someone already knows. Sometimes it's about their willingness to learn what they don't.

That willingness helped me move from building houses to building technology.

And as I'll talk about in Part 2, the technology never stopped changing.

Fortunately, neither did my willingness to learn.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

The Most Expensive Problems Are the Ones We Keep Fixing

There is an interesting trap in IT and software development. Sometimes we get really good at fixing a problem. So good, in fact, that we stop asking why we keep having to fix it.

A ticket comes in. Someone recognizes the issue. They know exactly what SQL query to run, which service to restart, which configuration to change, or which workaround to give the user. Problem solved. Ticket closed. Everyone moves on.

Then it happens again. And again. Eventually, what started as an exception becomes routine. That is when fixing the problem can actually become more expensive than solving it.

We Often Measure the Wrong Thing

Most technology organizations measure things like response time, resolution time, ticket volume, SLA compliance, and backlog size. Those measurements are important, but there is another question we should be asking:

Why did this ticket exist in the first place?

Closing 100 tickets quickly may look great on a dashboard. Preventing 80 of those tickets from ever being created is much better.

Think of it like repeatedly putting water into a leaking bucket. At some point, instead of getting better at filling the bucket, you probably need to fix the leak.

Technology organizations aren't much different.

When the Workaround Becomes the Process

Workarounds aren't necessarily bad. Sometimes they're exactly what we need. Production is down. A customer can't work. A critical process has stopped. You get things running again first. That's responsible operations.

The problem begins when the temporary workaround quietly becomes permanent.

Someone documents the workaround. Someone else learns it. Eventually the support team knows it. Then a new employee is trained on it. Before long, the organization has created an entire business process around something that was never supposed to exist in the first place.

At that point, we've stopped treating the workaround as temporary.

We've designed around the defect.

Tribal Knowledge Can Hide the Real Cost

This becomes even more dangerous when experienced employees make recurring problems look easy.

You've probably heard something like, “Oh, when that happens, just ask John. He knows how to fix it.”

That might sound reassuring, but what happens when John is on vacation? What happens when John leaves the company? More importantly, why does John need to keep fixing it?

Good people often compensate for bad processes. Because they're good at it, the organization sometimes doesn't realize how broken the underlying process actually is.

Every Repeat Has a Cost

One recurring problem might only take 15 minutes to resolve. That doesn't sound significant. But suppose it happens four times a week. That's an hour a week, or roughly 50 hours over the course of a year.

Now multiply that across several employees, environments, customers, or systems.

That still doesn't account for interruptions, context switching, investigation time, customer frustration, QA, management attention, or the opportunity cost of what those people could have been doing instead.

Suddenly, the little 15-minute problem isn't so little anymore.

Recurring problems compound.

The Ticket Should Leave Something Behind

This is why I believe a support or production ticket should produce more than a resolution. Whenever possible, it should leave behind knowledge.

What happened? What was the root cause? How was it diagnosed? What evidence confirmed the problem? What was done to correct it?

And most importantly: What would prevent this from happening again?

Sometimes the answer will be a code change. Sometimes it will be architecture or configuration. Sometimes it will be documentation, monitoring, training, or a better business process.

And sometimes the answer will simply be that fixing it permanently isn't worth the investment. That's okay too. The important thing is that we made that decision intentionally instead of allowing a workaround to become permanent simply because nobody questioned it.

Don't Confuse Activity With Progress

There is something satisfying about closing tickets. You can see the queue getting smaller. You can measure it. You can report it.

But activity and progress aren't always the same thing.

A team that closes 1,000 recurring tickets isn't necessarily performing better than a team that identifies the root causes and prevents 500 of those tickets from ever being created.

One team became better at fixing problems. The other became better at eliminating them.

That's an important distinction.

The Goal Isn't Zero Problems

Software will have defects. Infrastructure will fail. People will make mistakes. Requirements will change. Unexpected things will happen.

That's technology.

The goal isn't to create an environment where nothing ever goes wrong. The goal is to make sure we're learning from the things that do.

Because the most expensive problem isn't always the catastrophic outage everyone remembers. Sometimes it's the tiny problem everyone has learned to live with.

The one we've fixed hundreds of times. The one everyone knows the workaround for. The one nobody stops to question anymore.

Sometimes the most expensive problems are the ones we've become really good at fixing.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

I've said this before, and I think it is worth repeating: I am a big believer in AI.

I use it. I see tremendous value in it. I believe it is going to fundamentally change how we develop software, operate businesses, support customers, analyze information, and make decisions.

But there is an important difference between using AI as a tool and allowing AI to operate unchecked. That distinction becomes even more important as AI moves beyond simply answering questions and begins taking actions on our behalf.

AI Hallucinations Are Different When Actions Are Involved
We have all seen examples where an AI confidently provides an answer that simply isn’t correct. That is generally referred to as an AI hallucination.

When AI is being used as a research assistant or a thought partner, the consequences can often be managed. A person reviews the response, recognizes something doesn’t look right, verifies the information, and corrects it. That human review is an important part of the process.

But what happens when AI is no longer just recommending what should happen? What happens when it can actually do it?

Imagine an AI system that can modify a database, deploy code, change a firewall rule, disable a user account, send communications to customers, approve a transaction, or modify production infrastructure.

Now a hallucination isn’t simply a wrong answer on a screen. It can become a wrong action.

The Problem Gets Bigger as AI Gets More Access
There is an old principle in IT security called least privilege. You give a person or system only the access necessary to perform its job. There is a reason we have followed that principle for decades.

We learned, sometimes painfully, that convenience and security do not always point in the same direction. The same thinking needs to apply to AI.

If an AI agent has access to email, databases, source code, production environments, financial systems, customer information, and administrative tools, we should be asking some very traditional IT questions:

What does it actually need access to? What actions can it perform without approval? What requires human authorization? What gets logged? Can its actions be reversed? Who is accountable when something goes wrong?

These aren’t new questions. We have been asking them about users, administrators, applications, APIs, and service accounts for decades. AI shouldn’t suddenly be exempt from those same controls.

Human-in-the-Loop Should Not Be Considered a Weakness
There seems to be a race toward making AI completely autonomous. I understand why. The more AI can accomplish without human involvement, the greater the potential efficiency.

But efficiency should not automatically override control.

For high-impact decisions, having a human approve an AI-generated action may be exactly the right architecture. AI can analyze thousands of records. AI can identify patterns. AI can recommend an action. AI can prepare the change. And then a qualified person can review it and say, “Yes, execute.”

That extra step may add a few seconds or minutes to the process. It may also prevent hours, days, or millions of dollars of damage.

Trust, But Verify
That phrase existed long before artificial intelligence, but it may be one of the most important principles we carry forward into the AI era.

AI does not need to be perfect to be incredibly valuable. People aren’t perfect either. That is why mature organizations build controls around important processes.

We use peer reviews. We use change management. We separate development from production. We use approval workflows. We maintain audit logs. We test before deployment. We back things up. We limit administrative access.

AI should fit into those disciplines rather than bypass them.

The Future Should Be AI With Governance, Not AI Without Humans
I don’t believe the answer is slowing down AI adoption. I believe the answer is becoming smarter about how we adopt it.

AI should eliminate repetitive work, accelerate analysis, help developers build better software, help leaders make better-informed decisions, and allow organizations to accomplish things that previously required enormous amounts of time.

But capability and authority are two different things.

Just because an AI system can perform an action doesn’t mean it should always have the authority to perform that action without oversight.

The companies that ultimately get the most value from AI may not be the ones that simply give it the most access. They may be the ones that build the best guardrails around it.

Because the goal shouldn’t be to remove humans from every process. The goal should be to combine what AI does exceptionally well with the judgment, accountability, and experience that people bring to the table.

AI is an extraordinary tool. But like every powerful tool we have introduced into technology over the years, its value will ultimately depend on how responsibly we choose to use it.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Writing Code Is Not the Same as Building a SaaS Product

One of the biggest misconceptions in software development is that if someone can write code, they can build a software product. They are not the same thing.

A junior developer may be perfectly capable of taking a requirement and turning it into working code. A senior developer starts asking different questions. What happens when this fails? What happens when 10 users become 10,000? How will we support it? How will we monitor it? How do we upgrade it without breaking customers? What happens to the data? Is it secure? And perhaps most importantly: are we solving the right problem in the first place?

That difference becomes even more important when we talk about websites versus true SaaS applications.

A Website and a SaaS Application Are Different Things

Today, there are fantastic tools that allow someone to create a professional-looking website remarkably quickly. AI has made that even easier. But a good-looking interface is only the front door. A true SaaS application has an entire building behind it.

There are databases, APIs, authentication, authorization, security, logging, monitoring, backups, integrations, deployment pipelines, performance considerations, data retention, disaster recovery, scalability, and ongoing support.

Then comes another layer that is sometimes forgotten entirely: the business. Who is the customer? What problem are we solving? How does the customer actually use the product? What happens when their workflow doesn't match the workflow the development team imagined? And how do we continue improving the product without creating so much technical debt that every future change becomes harder than the last?

Junior Developers Build Features. Senior Developers Think About Consequences.

That isn't meant as criticism of junior developers. Everyone starts somewhere, and good junior developers can become outstanding senior engineers. The difference is often experience.

After you have lived through enough production outages, database problems, failed deployments, security incidents, performance problems, and seemingly "simple" changes that unexpectedly affected something else, you start thinking differently.

Instead of asking, "How do I make this work?" you begin asking, "How do I make this work reliably, securely, sustainably, and at scale?"

That is a very different question.

And Then There Is Product Thinking

Some of the best developers I've worked with don't immediately start coding when you give them a problem. They ask questions.

Why are we doing this? Who needs it? What are they doing today? What problem are we actually trying to solve? Is there already something in the platform that does this? What happens six months from now when the business changes?

Sometimes the best technical decision is not writing more code at all.

That kind of thinking is especially important in SaaS because every shortcut eventually becomes somebody's problem. It might become the support team's problem. It might become an infrastructure problem. It might become a security problem. Or it might become technical debt that the development team spends years trying to unwind.

AI Makes This Distinction Even More Important

AI can now generate remarkably good code. It can build interfaces, APIs, database structures, and even entire applications faster than many of us would have imagined a few years ago. I think that's a tremendous opportunity.

But generating code and engineering a sustainable product are still different things.

AI can help us build faster. Experience helps us understand what should be built, how it should be built, and what could go wrong after we build it.

That is why I don't believe the future belongs simply to the person who can write the most code. It belongs to people who understand systems, customers, operations, and consequences—and who can bring all of those things together.

Because ultimately, the goal isn't to build software that works during the demo.

The goal is to build software that still works when the demo is long forgotten and thousands of customers depend on it.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

We Spent 20 Years Locking Down Users. Now We're Giving the Keys to AI.

Let me start by making something very clear: I am a huge believer in AI. I use it, I see tremendous value in it, and I think tools like ChatGPT, Claude, Copilot and whatever comes next are going to fundamentally improve how we work.

AI can make people faster, eliminate repetitive work, help us analyze problems, write software, research ideas, improve customer service and automate processes that have frustrated businesses for years. The argument I'm making isn't that AI is bad. The argument is that something this powerful shouldn't be unchecked.

For the last 20-plus years, IT organizations have spent enormous amounts of time limiting what users, applications and systems are allowed to do. We removed local administrator rights, implemented MFA, restricted Remote Desktop, created firewall rules, segmented networks, introduced conditional access, built privileged accounts and implemented change control.

Behind nearly all of those decisions was one very old security principle: Give someone only the access they actually need. Least privilege.

But now something interesting is happening. After spending decades locking everything down, we're beginning to hand increasingly powerful access to AI.

AI Is No Longer Just Answering Questions

When ChatGPT and Claude first appeared, most people interacted with them primarily as assistants. Ask a question, get an answer. Write an email, summarize a document, analyze some code or brainstorm an idea.

We're quickly moving beyond that. AI is becoming agentic. Instead of simply telling us what to do, we're increasingly allowing AI to do things for us.

Give AI access to email. Then calendars. Then OneDrive or Google Drive. Then GitHub. Then the CRM. Then the browser. Then local files, APIs and business applications.

Every one of those connections makes AI more useful, and that's a good thing. But every connection also gives AI more authority.

At some point, AI isn't simply another application. It's another identity inside the business, and potentially a very powerful one.

We've Seen This Movie Before

Anyone who has worked in IT long enough remembers when Remote Desktop was primarily viewed as a convenience. Why drive somewhere when you can remotely connect to the computer?

Remote access wasn't bad technology. It was incredibly useful technology. The problem came when powerful remote access was deployed without adequate controls. Attackers learned to exploit poorly secured remote access for compromised systems, ransomware, credential theft and lateral movement.

The lesson wasn't "Stop using remote access." The lesson was "Powerful capabilities require appropriate controls."

So we adapted. VPNs, MFA, firewalls, conditional access, network segmentation, privileged access management and logging. We didn't abandon the technology. We learned how to use it responsibly.

AI deserves exactly the same approach.

The More AI Can Do, the More Governance Matters

Imagine an AI agent with access to your email, files, source code, customer database, CRM, accounting system, browser, internal applications and APIs.

Now ask yourself: If this were a human employee, would I give one person unrestricted access to all of this?

Probably not.

That doesn't mean we shouldn't connect AI to these systems. There are enormous productivity benefits in doing so. But access should be intentional.

If AI needs to read something, does it also need permission to modify it? If it needs to prepare an email, does it automatically need permission to send it? If it analyzes financial information, does it need authority to execute a transaction? If it examines production systems, does it need permission to make production changes?

Those aren't arguments against AI. They're the same access-control questions IT has been asking for decades.

Shadow IT Is Becoming Shadow AI

There's also a much more immediate challenge. While executives and IT departments debate which enterprise AI platforms they should approve, employees are already using AI.

Someone uploads an Excel spreadsheet to a personal AI account. Someone pastes company information into an AI assistant. A developer installs an AI coding tool. Someone connects an AI assistant to cloud storage. Someone else gives an AI agent access to their browser.

We've dealt with Shadow IT for decades. Now we're beginning to deal with Shadow AI.

Simply banning AI probably isn't the answer. If a technology genuinely makes people more productive, people will find ways to use it. Organizations should instead provide employees with approved, secure ways to use these tools.

Governance should enable AI, not prevent it.

Use AI Aggressively. Govern It Intelligently.

There are two extremes. One organization says, "AI is too dangerous. Nobody can use it." Another says, "AI is amazing. Connect it to everything."

Neither approach makes much sense.

The better answer is somewhere in the middle: Use AI aggressively, but govern it intelligently.

Give employees access to approved AI platforms. Protect corporate information. Apply least privilege. Require human approval for consequential actions. Log what AI systems access and change. Review integrations before connecting AI to critical systems. And don't give an AI system authority simply because giving it that authority is convenient.

We've traditionally managed identities for employees, administrators, contractors, applications, service accounts and devices. Now we're adding another: AI agents.

What systems can the AI access? What information can it read? What can it modify? What actions can it perform? Who authorized those permissions? Can those permissions be revoked? Can we determine what it did afterward?

Those aren't anti-AI questions. They're responsible IT governance questions.

Don't Fear AI. Manage It.

AI has enormous potential, and I believe businesses that embrace it intelligently will have a significant advantage over those that don't.

But embracing AI doesn't mean abandoning decades of good IT practices.

Least privilege still matters. Separation of duties still matters. Change control

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/