Diego Salcedo manages an 11-person operations team at a regional logistics company. Last quarter he found the perfect AI tool for automating shipment exception handling, ran a successful two-week trial, and walked into the IT director's office expecting a quick yes. Instead he got a list of 14 questions he could not answer: Where does the data live? Who can see customer addresses? What happens when the vendor has an outage at 2 a.m.? Diego left frustrated, convinced IT was the enemy of progress. Six weeks later, after he learned to bring those answers before the meeting instead of after, the same tool was approved in nine days. The tool never changed. His approach did.

What This Lesson Covers

Partnering with IT on AI infrastructure is the skill of getting AI tools into your team's hands quickly without creating security, compliance, or reliability problems that land on someone else's desk. As a team-level manager you are not setting enterprise architecture policy. But you are the person who decides which tools your team tries, and how those requests reach IT. Done well, that makes you the manager IT wants to say yes to. Done badly, it makes you the source of shadow tools and Monday-morning incidents.

This lesson covers what IT actually worries about and why those worries are legitimate, how to write a request that gets a fast answer, how to run a joint pilot instead of an ambush, and how to navigate the four conflicts that derail most business-IT AI conversations. We will follow Diego through one real request from rejection to approval.

It also covers why the partnership is worth the effort in the first place, how to learn IT's perspective before you need something, which constraint questions to ask before you commit, how to address concerns proactively rather than defensively, how to help IT build its own AI capability, why celebrating together is not just manners, what governance that enables rather than blocks looks like, and the three patterns that break the relationship entirely.

What IT Actually Worries About

When Diego heard "no," he assumed IT was being obstructionist. They were not. They were responsible for things he had not considered. AI tools introduce concerns that do not show up in a two-week happy-path trial.

IT carries four standing worries about any new AI tool. Data exposure: what customer or internal data the tool can see, and where that data physically travels and rests. Reliability: what happens to your team's work when the vendor degrades or goes down, since IT owns the support ticket either way. Compliance: whether the tool's data handling triggers a regulation your company is bound by. Integration and support: whether the tool will need to connect to internal systems, and who maintains that connection a year from now.

It is worth unpacking each of those a little further, because the detail is what lets you pre-answer them. On security, AI brings genuinely new risks: data exposure, manipulation of the model, and adversarial attacks that IT has to understand before it can mitigate them. When a manager says "we want to deploy this AI chatbot," the questions that come back about what data it can access, how that data is secured, and what happens if the model is compromised are not obstacles. They are the job. On reliability, AI systems fail in ways traditional software does not: models degrade over time, data quality problems surface as bad output rather than error messages, and integrations break silently, all of which IT has to learn to monitor and maintain. On compliance, many industries carry regulations about data, privacy, and automated decision-making, and IT is the function that keeps you operating legally and ethically. On integration, AI systems never exist alone; they connect to systems that already exist, and that work is complex and slow.

Two further concerns sit behind those four and surface later rather than at approval. Scalability: as the business wants to scale AI, the infrastructure has to scale with it, and not every AI setup that works as a pilot survives the move to enterprise volumes. Talent and skills: IT teams need new capabilities to support AI, including managing models, data pipelines, and integrations, and those skills take time to develop. When you ask IT to deploy AI fast, they are weighing all six of these at once. That is not obstruction. It is responsibility.

IT is not slow because it dislikes your idea. It is slow because it is being asked to absorb a risk it cannot see yet. Your job is to make the risk visible and small.

The reframe that changed Diego's results was simple. He stopped treating IT's questions as obstacles to argue past and started treating them as the actual checklist for getting approved. Every question on that list of 14 was a thing he could answer in advance.

Why the Partnership Is Worth Building

The tension between business and IT is common enough to feel inevitable. Managers see IT as a constraint that says no, moves slowly, and does not understand the business. IT sees managers making demands without understanding technical reality. Business wants it fast; IT needs it right. Both descriptions contain some truth, and the relationship is damaging in exactly the proportion that both sides believe them.

Without partnership, the pattern is predictable. Business pushes for speed, IT resists, business eventually goes around IT and adopts tools independently, IT loses visibility and control, and organizational risk rises without anyone deciding to accept it. Diego's first attempt was two steps into that sequence before he changed course.

With partnership, the same conversation runs differently. Business explains clearly what it needs and why. IT explains its constraints and the real trade-offs. Between them they find solutions that serve business agility and IT responsibility at the same time. Four outcomes follow.

• Faster time to value, because IT enables speed wherever speed is actually safe.
• Appropriate risk management, because the business understands and consciously accepts the risks IT has raised rather than ignoring them.
• Better build-versus-buy decisions, because both sides decide jointly what to build internally and what to purchase.
• Sustainable solutions, because what gets deployed is designed to scale and to be maintained by someone a year from now.

Start by Learning Their Perspective

The best time to understand IT is before you want something from them. Diego's mistake was that his first substantive conversation with the IT director was a request. Invite the IT leader responsible for your area to a conversation with no ask attached, and use it to ask four questions.

• What are your biggest concerns about AI adoption?
• Which security risks worry you most?
• How would you prefer AI tools to be integrated here?
• What would make your job easier?

Then listen without defending your position. The instinct to explain why your case is different is the thing that ends these conversations early. You are there to understand constraints, not to negotiate. Diego did this in week three of his six-week reset, and roughly half of the eventual one-page request came straight out of what he heard.

Writing a Request IT Can Act On

Most AI requests die because they are vague. "We want to use an AI tool for shipment exceptions" gives IT nothing to evaluate, so the default answer is a stalling question. Compare that to what Diego brought the second time.

His one-page request specified the business outcome (cut exception resolution from an average of 4 hours to under 1 hour, on roughly 600 exceptions a month), the exact data the tool would touch (shipment IDs, status codes, and carrier names, with no customer addresses or payment data), the deployment model (vendor SaaS, data processed in the vendor's US region, retained 30 days), the scale (11 users, about 600 transactions monthly), and the timeline (live within six weeks). He also named what he did not need: no integration with the customer database, because he would paste exception records manually for the pilot.

That last line mattered more than any other. By scoping the customer database out of the pilot, Diego removed the single biggest security concern before IT raised it. A good request does not just state what you want. It pre-answers the worry by limiting blast radius.

The underlying pattern generalizes to any AI request, and the IT director gave Diego a second illustration of it from a different department. The weak version is "we want to use AI chatbots." The strong version names the business need, the scope, the scale, and the timeline in one breath: we want to deploy an AI chatbot to handle customer service inquiries, aiming to handle 60 percent of routine inquiries automatically and improve response time from 2 hours to 15 minutes; it needs access to the customer database and the knowledge base; we estimate 50,000 conversations per month; we need it deployed in 3 months. Every one of those clauses is something IT can size, question, or plan around. The vague version gives them nothing to work with except delay.

Ask About Constraints Before You Commit

Once IT understands your need, turn the conversation around and ask what you are working within. Five questions cover most of it.

• What data can we safely use with this kind of tool?
• How should we be handling data security for it?
• Which integration approaches make the most sense given what we already run?
• What is a realistic timeline given your team's capacity?
• What skills or resources would you need to support this?

Asking these before you commit to a date with your own stakeholders is what makes your plan realistic rather than optimistic. Diego promised his director six weeks only after IT told him what six weeks would actually require.

Running a Joint Pilot, Not an Ambush

Diego's first mistake was running a pilot alone and presenting it as a finished decision. IT had no visibility, so from their seat it looked like shadow IT that had already happened. The fix was to invite IT into the pilot as a co-owner from day one.

A joint pilot has four checkpoints. At kickoff, business and IT agree on success criteria and the data boundary together. Midway, IT reviews what data actually flowed and confirms it matched the agreement. At the end, both sides assess results against the criteria. And before any expansion, they decide together what changes if the tool moves from 11 users pasting records manually to an integrated system serving the whole department. Staged expansion is the point. The pilot earns trust precisely because it is small and reversible.

Those checkpoints are one expression of four collaborative habits worth naming explicitly, because they apply well beyond a single pilot. Joint planning means business and IT plan the implementation together rather than one handing a specification to the other. Staged rollout means phases with learning built in rather than a single large launch. Shared ownership means both sides own the outcome, not just their half of the handoff. Regular checkpoints mean you meet on a rhythm to assess progress and adjust. The mental shift underneath all four is to stop treating IT as a service provider taking your order and start treating them as partners in the result.

This is where a RACI chart earns its keep. For Diego's pilot, the tool selection and business case were his to own (Responsible) with his director Accountable; data-boundary approval and the security review were IT's to own (Responsible) with the IT director Accountable; and both he and IT were Consulted on the integration decision. Writing this down took ten minutes and ended the "I thought you had that" gaps that sink joint projects. Nobody could later claim a security gate was someone else's job.

Address Concerns Before They Become Objections

When IT raises a concern, work it rather than waiting for it to fade. It will not fade, and an unaddressed concern reappears at the worst possible moment, usually the week before you planned to go live.

Take data security on an AI tool as the example, since it is the concern that comes up most. Working it means answering four questions together, in writing: which data can be used safely, what security measures the tool needs around it, how you will test that security before production rather than after, and who owns ongoing security monitoring once the thing is live. None of those are questions a business manager answers alone, which is the point. Sitting down to answer them jointly is itself the trust-building act. Diego found that the second and fourth questions in particular were ones IT had expected to have to chase him for, and volunteering them changed the temperature of the whole conversation.

Help IT Build Its Own AI Capability

Part of what makes IT cautious about AI is that supporting it requires skills their team may not have yet. Recognizing that, and helping rather than pressuring, is one of the highest-return moves available to a business manager.

Practically, that means backing time for their training and learning rather than treating every hour as capacity stolen from your project. It means supporting bringing in external expertise when a gap is genuinely beyond the team. It means giving IT space to experiment with new tools on their own terms, the same way you would want for your team. And it means favouring vendor relationships where the supplier will actually support and upskill your IT people rather than leaving them with a manual. When IT feels supported in developing capability rather than judged for lacking it, they become far more willing to embrace the next AI initiative you bring.

Celebrate the Win Together

When the implementation works, share the credit publicly and specifically. This is not politeness. It is recognition of a real contribution: IT made significant decisions and did significant work to make the thing viable, and that work is invisible by nature, which is precisely why it needs naming.

There is a self-interested reason too. When IT sees its work producing visible business value with its name attached, it becomes invested in the next AI initiative rather than braced for it. Diego made a point of naming the two IT people who ran his security review when he reported the exception-handling results upward. The next request he filed moved noticeably faster.

Navigating the Four Recurring Conflicts

Even a well-run partnership hits friction. Four conflicts recur, and each has a navigable path.

• Speed versus security. You want it live this month; IT wants it secured first. Ask for the minimum viable secure version. Diego's answer was the manual-paste pilot with no customer data, which let IT approve a limited deployment fast and add integration security later. The two are not mutually exclusive once you are willing to deploy with limited data first, add security layers iteratively, or pilot before going to full scale.
• Build versus buy. You prefer buying because it is faster; IT may prefer building for control. The honest default is buy the standard thing and build only what is genuinely unique to your business. Exception triage is not unique, so buying was correct. Evaluate each case on its merits rather than on either side's habit.
• Vendor risk. IT worries about lock-in, vendor viability, and data ownership. You can defuse this by checking the contract for data ownership and an exit clause before you fall in love with the tool, and raising it yourself rather than waiting for IT to find it. Negotiate those terms into the contract where you can, and for genuinely critical systems, avoid depending on a single supplier.
• Resource constraints. IT has security patches, keeping existing systems running, and other initiatives competing with your request. Help them prioritize by stating the business impact in their terms, be honest about what resources the work needs, and offer to absorb work your team can do, like documentation or first-line user support. Then be realistic about timelines given the capacity they actually have.

The pattern across all four is the same: name the trade-off out loud, shrink the first commitment, and give IT a way to say yes to something small.

Staying Out of Shadow IT

The worst outcome for a manager is the one Diego nearly chose: getting frustrated and quietly rolling out the tool anyway. When teams adopt AI tools outside IT's view, the company accumulates invisible data exposure, integration gaps, and compliance violations that surface later as a crisis with your name attached. The frustration is understandable. The workaround is never worth it.

If IT genuinely moves too slowly, the fix is to improve the process together, not to bypass it. Propose a lightweight fast lane: a one-page request template like Diego's, a target turnaround of ten business days for low-risk tools, and a clear escalation path for the rare novel case. Light, fast, collaborative governance gets you more AI adoption than going around IT ever will, because the tools you get approved actually stay.

Governance That Enables Instead of Blocking

Most business-IT conflict is really a governance problem in disguise, and it fails in two opposite directions.

Governance that is too loose, where business can adopt tools with no IT involvement at all, produces shadow IT that nobody has an inventory of, security risk from data flowing through tools IT does not monitor, integration problems because none of the tools talk to each other, and compliance issues from tools that quietly violate policy.

Governance that is too tight, where every adoption needs extensive approval, produces its own damage: innovation slows to a crawl as good ideas wait months, frustration builds until people route around the process entirely, and the process turns brittle, breaking on the first case it was not designed for.

Good governance sits between the two and is deliberately light. It rests on clear principles, meaning a shared understanding of what actually matters here: security, compliance, integration. It runs a fast review process measured in days rather than weeks. It uses escalation paths so routine decisions move quickly while genuinely novel ones get proper scrutiny. And it improves continuously, meaning when the governance itself is causing problems you change it rather than defending it. Governance built that way enables innovation and addresses legitimate concerns at the same time, which is the only version that survives contact with a motivated manager.

Three Ways the Relationship Breaks

Business goes around IT. Frustration with IT's pace leads a manager to adopt tools independently. IT is not involved, security risk accumulates, integration problems emerge, and when the shadow IT is eventually discovered the conflict is worse than the original delay ever was. The alternative is to build the partnership, and if IT genuinely is too slow, to fix that together. Routing around IT always creates a bigger problem than the one it solves.

IT blocks everything. The mirror image. IT says no to every new AI tool, and while the concerns are real, they are not proportionate to the actual risk. Business grows frustrated and stops trusting IT's judgment even when the judgment is right. The way through is to find the root of the concern rather than arguing with the verdict. Is it legitimate? Can it be addressed? Can a small pilot demonstrate safety in practice rather than in theory?

No real partnership. The subtlest one, because on the surface it looks fine. Business and IT do work together, but transactionally: business asks, IT builds, IT hands it over. There is no genuine collaboration, so when something goes wrong the first response is blame rather than joint problem-solving. The alternative is owning outcomes together and solving problems together, which is a different relationship rather than a better version of the same one.

Terms Worth Knowing

• Shadow IT: technology adoption that happens outside formal IT governance, usually created when the business moves faster than the formal process allows.
• Vendor lock-in: dependency on a single vendor that makes switching to an alternative costly or difficult.
• Vendor viability: confidence that a vendor will continue to exist and support their product over time.

Put This Into Practice

Four exercises, and the first one is a real conversation rather than a thought experiment.

• Meet your IT counterpart. Identify the IT leader you need to partner with on AI, schedule a conversation with no ask attached, and use it to understand their concerns about AI adoption. Listen more than you explain.
• Write the one-page request. Take an AI initiative you are considering and prepare it for IT: business need, data required, scale, timeline, and the questions you have about technical feasibility.
• Work a live conflict. Pick a real business-IT tension at your organization, about speed, security, resources, or something else, and work out how you would address it and what partnership would look like as the route to a solution.
• Design the governance. Sketch governance for AI tool adoption in your organization that enables innovation while addressing IT's legitimate concerns. Say how fast routine approvals should be and what gets escalated.

Reflection

Three questions to sit with.

• How would you characterize the relationship between business and IT at your organization, partnership or tension, and why?
• What is the biggest single barrier to a better partnership where you work, and how would you address it?
• If you could improve the business-IT relationship, what specifically would change, and what would the impact be?

Where This Leaves You

The organizations that do this well are the ones where business and IT operate as genuine partners. Business understands the technology constraints and the trade-offs behind them. IT understands the urgency and the opportunity the business is chasing. Neither has to become the other, and together they make better decisions than either would alone.

AI adoption at scale needs both halves. Business supplies the vision and the urgency; IT supplies the wisdom about risk, security, and what will still be standing in two years. Invest in that relationship: understand their perspective, communicate clearly, and solve problems jointly rather than sequentially. Diego's tool got approved in nine days the second time not because he found a better argument, but because he had spent six weeks becoming the kind of manager IT could say yes to.

Key Takeaways

• Treat IT's questions as the approval checklist, not obstacles. Data exposure, reliability, compliance, and integration are legitimate concerns you can pre-answer before the meeting instead of getting blindsided in it, and scalability and IT's own skill gaps sit behind them.
• Partnership beats both alternatives. Working together produces faster time to value, risk that is consciously managed, better build-versus-buy calls, and solutions someone can still maintain next year.
• Learn their perspective before you need something. Ask what worries them, which risks concern them, how they want tools integrated, and what would make their job easier, then listen without defending.
• Write requests with outcome, data, scale, and timeline. A specific one-page request gets a fast answer; "we want to use an AI tool" gets a stalling question.
• Shrink the blast radius first. Scoping sensitive data and integrations out of the pilot removes the biggest worry before IT raises it.
• Run pilots jointly with a RACI chart. Invite IT in as a co-owner with clear Responsible and Accountable roles so no security gate falls through a "I thought you had that" gap, and work concerns proactively rather than waiting for them to resurface.
• Navigate the four conflicts by shrinking the first commitment. For speed-vs-security, build-vs-buy, vendor risk, and resource limits, name the trade-off and give IT a small, reversible yes.
• Support IT's capability and share the credit. Back their training, external expertise, and room to experiment, then name their contribution publicly when the implementation works.
• Never route around IT. Shadow AI adoption trades a few weeks of speed for a future incident with your name on it. Fix a slow process together instead.
• Aim for governance that is light and collaborative. Clear principles, approvals in days not weeks, escalation paths for the novel cases, and a willingness to change the process when it is the thing causing the problem.