Working with IT, Security, and Procurement: The New Collaboration Trio

Welcome & Series Roadmap

Hello, and welcome to the Designing with Love Podcast. I am your host, Jackie Pellegrin, where my goal is to bring you information, tips, and tricks as an instructional designer. Hello, instructional designers and educators. Welcome to episode 125 of the Designing with Love Podcast. As we continue through the 2026 lineup, we're also moving through the AI Ready Designer Series. Last time, we explored AI tutors and practice spots, so you can use them intentionally. Today we'll cover what these teams care about and what to bring, so approvals don't become a brick wall. So grab your notebook, a cup of coffee, and settle in as we explore this topic together. Before we jump in, a quick note. This is a 12-episode arc and each episode builds on the last. In this 12-episode AI ready designer series, we'll move through five AI ready checkpoints each time, so you always leave with something practical you can apply right away.

AI Tool Choices Become Cross-Functional

Alright, let's jump into checkpoint one. Here's the shift. Instructional designers are no longer just choosing authoring tools, templates, LMS features, or media assets. Now we may be evaluating tools that involve learner data, employee data, prompts and uploads, integrations with existing systems, vendor contracts, privacy rules, accessibility requirements, and security reviews. That means AI tool decisions are not just learning design decisions. They are also technology decisions, risk decisions, and purchasing decisions. And that is where IT, security, and procurement become part of the workflow. This may feel frustrating at first, especially when you're trying to move quickly. You find a tool that looks perfect. You can already imagine the learning experience, and then suddenly you hear, has IT approved this? Did security review it? Do we have a contract? Where is the data going? Can we use this with employees or students? And it can feel like momentum just crashed into a wall. But here's the reframe for today. These teams are not there to block learning. They are there to protect the conditions that make learning safe, sustainable, and scalable. That does not mean every process is perfect. Sometimes approvals are slow. Sometimes the path is unclear. Sometimes the answer changes depending on the tool, the data, and the use case. But the more we understand what each team cares about, the better we can prepare. AI approval is easier when you bring clarity before you bring urgency. So that's the big shift. AI work is more cross-functional now. Next, let's ground this in what stays true about our role as instructional designers.

Four Traps That Slow Approval

What doesn't change is this. Instructional designers are still responsible for connecting tools to learning purpose. IT may ask whether the tool works. Security may ask whether the tool is safe. Procurement may ask whether the purchase makes sense. But we have to answer a different question. How does this tool support learning, performance, practice, feedback, or transfer? That is our lane. And that is important because not every shiny AI tool deserves a place in the learning ecosystem. Some tools look impressive in a demo, but they do not solve a real instructional problem. Some tools generate content quickly, but they do not improve practice or performance. Some tools seem affordable at first, but create hidden work later because they do not integrate well, meet accessibility needs, or fit existing workflows. So your role is not to say, I like this tool. Your role is to say, here is the learning need, here is the use case, here is the audience, here is the type of data involved, here is the risk level, and here's how we will evaluate whether it works. That is a much stronger conversation. And when we do not bring clarity, we run into predictable problems. So let's talk about the risks. The risk in this episode is not simply that IT, security, or procurement might say no. The bigger risk is that we enter the conversation too late with too little information. That is when approvals start feeling like a brick wall. Here are four common traps. Trap number one, starting with the tool instead of the use case. If we say, can we buy this AI tool, the conversation becomes a yes or no decision. But if we say, we need a safe way for learners to practice customer conversations and receive feedback, now we are talking about a learning problem. The tool is part of the answer, not the whole conversation. Trap number two, not knowing what data is involved. This is where things get sticky fast. Will learners type personal information into the tool? Will employees upload internal documents? Will the tool store prompts? Will the vendor use content for training? Will data move outside approved systems? If we cannot answer basic data questions, security has to slow things down. Not because they are difficult, but because risk is unclear. If IT, security, or procurement only show up after you have already built the solution in your head, their feedback feels like a delay. But if they are involved earlier, their questions can shape a better solution. Early collaboration saves emotional damage. I said what I said. Trap number four, treating approval like a one-time event. Approval is not always yes forever. A tool may be approved for one use case, but not another. For example, a tool may be fine for public content brainstorming, but not approved for learner data, employee evaluations, or internal policy documents. So the question is not just is this tool approved? The better question is approved for what use, with what data, and under what conditions. So if those are the traps, the upgrade is learning how to speak the language of each team before the approval conversation starts.

What IT, Security, & Procurement Ask

Here is the upgrade. Instead of seeing IT, security, and procurement as obstacles, think of them as three different lenses. Each team is asking a different version of the same question. Can this tool be used responsibly here? Let's break it down. IT. Will it work for our environment? IT is often thinking about integrations, account access, single sign-on, compatibility, support needs, system reliability, and implementation workload. They may ask the following questions. Does this integrate with our LMS or existing tools? Who will manage accounts? What happens if the tool breaks? Did it create extra support burden? Is there an enterprise version? So when you talk with IT, bring the workflow, not just here's the tool. Bring the following. Who will use it, where it fits, what system it touches, and what support learners or designers may need. Security, what risk does this create? Security is thinking about data privacy, sensitive information, vendor data practices, access controls, storage and retention, compliance requirements, and misuse or unintended exposure. They may ask the following questions What data goes into the tool? Is any of it personal, proprietary, or regulated? Where does the data go? Who can access it? Can the vendor use it to train models? What happens if someone pastes the wrong thing? So when you talk with security, bring the risk tier. Use what we discussed earlier in the series. Tier one, public and low risk. Tier two, internal and sensitive. Tier three, regulated or personal data. That helps them evaluate the real risk instead of guessing. Procurement, is this purchase worth it and manageable? Procurement is thinking about cost, contract terms, renewals, licensing, vendor requirements, duplication with existing tools, cancellation terms, and value for the organization. They may ask the following questions. Do we already have a tool that does this? How many seats do we need? Is the pricing clear? What are the contract terms? Who owns the relationship with the vendor? What problem is this solving that justifies the cost? So when you talk with procurement, bring the value case, not a 20-page business proposal. Just enough clarity to explain what the tool supports, who benefits, what time or quality problem it solves, and how you will know if it is worth keeping.

The One-Page AI Approval Brief

Now let's make this practical with a simple approval brief you can use before you request, recommend, or pilot an AI tool. Here's your next move. Create a simple AI approval brief. This is not meant to be complicated. It's a one-page summary that helps IT, security, procurement, and learning leaders understand what you are asking for. Your brief has five parts. Part one, use case. What are you trying to do? For example, generate first draft scenarios, support learner practice, summarize feedback themes, create job aid drafts, and build a chat bot for low stakes concept review. Keep it specific. Part two, audience. Who will use the tool? Instructional designers, facilitators, learners, managers, SMEs, students, and external clients. This matters because risk changes depending on who is using it and how. Part three, data. What information will go into the tool? This is where you name the data type, public information, internal documents, learner responses, employee data, client data, confidential processes, and personal information. If the answer is none, say it clearly. If the answer is we will use placeholders only, say that too. Part four, risk tier and guardrails. What level of risk is involved? Use the simple tier language. Tier one, public and low risk, tier two, internal and sensitive, tier three, regulated or personal data. Then add your guardrails. For example, no student or employee names, no confidential documents, approved prompts only, human review before publishing, use only inside approved accounts, no use for final decisions. Part five, value and evaluation. Why is this worth considering and how will you know if it worked? This might include reducing draft time, improving practice quality, increasing consistency, supporting accessibility, improving feedback loops, and reducing rework. Then choose one or two ways to evaluate it. For example, time saved, quality of drafts, SME review time, learner satisfaction, reduction and revision cycles, and improved scenario quality. The goal is not to oversell the tool. The goal is to show that you have thought through the purpose, risk, and value. Let me give you a quick field note so you can hear how this changes the conversation. Imagine an instructional designer finds an AI tool that creates role play simulations. The first version of the request sounds like this. Can we buy this tool? It would be great for training. This is vague, so IT, security, and procurement all have to ask a hundred questions. But the stronger version sounds like this. We want to pilot this tool for customer service role play practice. Learners will not enter personal customer data. We will use pre-written scenarios. The tools support low stakes practice only. Feedback will be based on our rubric and an ID will review outputs before launch. We want to evaluate whether it reduces facilitator prep time and improves scenario consistency. That is a very different conversation. It does not guarantee approval, but it gives the collaboration trio something useful to respond to. And that's the point. You are not just asking for permission, you are bringing a responsible design plan.

Challenge Resource & Closing

Alright, let's make this practical with this week's checkpoint challenge. This week's checkpoint challenge is simple. Think of one AI tool, feature or workflow you are curious about using. Then create a rough AI approval brief with five lines. Use case, what will we use it for? Audience, who will use it? Data, what will go in it? Wrist tier, what garbrails are needed? Value, how will we know it helped? That is it. Even if you never submit it formally, this exercise will make you a stronger partner in the approval conversation. And to make that easier, I created a quick companion resource for this episode. Before you go, I made an interactive companion called AI Approval Compass. It's a quick click-through guide you can use to prepare for conversations with IT, security, and procurement before you recommend or pilot an AI tool. If this episode helped you, please follow or subscribe and share it with a designer who is trying to navigate AI approvals without getting stuck at the brick wall. Working with IT, security, and procurement may feel like extra work at first, but in the AI era, collaboration is part of responsible design. When you bring a clear use case, name the data, identify the risk, and explain the value, you make it easier for other teams to help you move forward safely. Before I conclude this episode, here's an inspiring quote by Helen Keller. Alone we can do so little, together we can do so much. There is good evidence that Helen Keller used this line in public remarks, and it fits this episode beautifully because AI readiness is not solo work, it is shared work. Thanks for spending time with me today. Until next time, keep it practical, keep it human, and keep designing with love. Thank you for taking some time to listen to this podcast episode today. Your support means the world to me. If you'd like to help keep the podcast going, you can share it with a friend or colleague, leave a heartfelt review, or offer a monetary contribution. Every act of support, big or small, makes a difference, and I'm truly thankful for you.