AIN 712: Strategic Leadership in AI

AIN 712: Strategic Leadership in AI was one of the most practical courses in my Master’s in AI program at Wake Forest. The course was not about learning how to code an AI model. It was about learning how to lead when AI becomes part of a real business.

That distinction matters. A company can buy AI tools, test AI pilots, and talk about innovation all day long. That does not mean it has an AI strategy. A real AI strategy connects technology to business value, risk management, employee adoption, operating discipline, and measurable outcomes. That was the main theme of the course.

The class moved week by week through the actual leadership questions executives face when they bring AI into an organization. What problem are we solving? Is AI the right tool? What value should it create? Who owns the decision? What could go wrong? How do employees respond? How do we know whether the work is actually helping the business?

Those questions sound simple, but they are where many AI projects fail.

What the Course Covered
The course began with AI readiness and leadership problem definition. This was important because AI should not start with a tool looking for a problem. It should start with a business problem worth solving. The early readings helped frame AI as a leadership challenge, not just a technical project. Bevilacqua, Ferraris, Matzler, and Kudej (2026), for example, focused on how AI changes the skills required of senior leaders. The idea is that leaders do not need to become engineers, but they do need to understand AI well enough to ask better questions, make better trade-offs, and avoid being impressed by technology for technology’s sake.

The course then moved into AI business value. Enholm, Papagiannidis, Mikalef, and Krogstie (2022) helped frame AI value as something that comes from more than automation. AI can create value through better decisions, improved processes, new products, stronger customer experiences, and better use of organizational data. But the value does not appear automatically. The organization has to connect AI to the way work actually gets done.

That was one of my biggest takeaways. AI does not create business value just because it exists. It creates value when it improves a real workflow, solves a real problem, or helps people make better decisions.

The course also spent a lot of time on why AI projects fail. Verma (2025) argued that agentic AI projects only succeed when organizations approach them with “discipline and strategic intent.” That phrase stuck with me because it is the opposite of how many companies talk about AI. There is a lot of excitement around agents, automation, and productivity, but excitement is not the same as execution. Griffy-Brown (2021) also emphasized that AI projects often fail because of weak data, unclear goals, poor governance, and unrealistic expectations.
That lesson connects directly to leadership. A failed AI project is rarely just a technology failure. It is usually a leadership failure first. Someone did not define the use case clearly enough. Someone did not understand the data. Someone did not assign ownership. Someone did not think through adoption. Someone did not measure the right thing.

Responsible AI and Governance
Another major part of the course was responsible AI. This was not treated as a legal footnote or a compliance checklist. It was treated as a leadership responsibility.

The course included readings on algorithmic accountability, including the Robodebt case in Australia. Nikidehaghani, Andrew, and Cortese (2023) showed how automated decision-making can create serious harm when accountability becomes blurred. The lesson was not simply “AI can be dangerous.” The deeper lesson was that organizations can hide behind systems. When something goes wrong, people may say the model made the decision, the process required it, or the data supported it. That is exactly why leaders need clear accountability.

We also studied governance frameworks such as the NIST AI Risk Management Framework and the EU AI Act. NIST organizes AI risk management around four major functions: Govern, Map, Measure, and Manage (NIST, 2023). I found that useful because it makes responsible AI operational. It is not enough to say, “We care about responsible AI.” Leaders have to govern the work, map the risks, measure performance, and manage issues over time.

The EU AI Act also introduced the idea that not all AI systems carry the same risk. Some AI uses are low risk. Others are high risk and require stronger documentation, human oversight, transparency, and monitoring. That matters because leaders should not govern every AI use case the same way. A chatbot that summarizes meeting notes is different from an AI system that affects lending, hiring, healthcare, pricing, or public benefits.

The big lesson for me was that responsible AI should be built into the workflow. It should not live in a separate PowerPoint deck. If the risk is real, then the controls need to show up in the day-to-day work: review thresholds, audit logs, escalation rules, human oversight, and stop/pivot/scale criteria.

Change Management and Employee Adoption
The course also made clear that AI adoption is not just a systems rollout. It is a people issue.

Trimboli (2025) focused on structured dialogue as a way to improve change readiness and employee well-being during AI adoption. That made sense to me. Employees are not machines that instantly accept a new workflow because leadership says it is better. People want to know what AI means for their jobs, their autonomy, their performance reviews, and their future.

Gibbard, Gill, Powell, and others (2026) examined how explanations can increase trust in workplace generative AI. That idea is simple enough for a 15-year-old to understand: people are more likely to trust a system when they understand why it is making a recommendation. If AI gives an answer but cannot explain itself, people may either trust it too much or ignore it completely. Both are dangerous.

That lesson shaped my thinking throughout the class. AI adoption is not just about usage numbers. A person can log into a tool every day and still use it poorly. Real adoption means people understand the tool, use it appropriately, know when to question it, and know how to document their decisions.

The course also included a video called “The GenAI Productivity Trap: Why Faster Isn’t Always Better.” That idea became very important in my final project. AI can make work faster, but faster is not automatically better. If AI helps someone make a bad decision faster, the company has not improved. It has simply accelerated the problem.

My AI Leadership Strategy Portfolio
The major assignment in the course was a full AI Leadership Strategy Portfolio. Each milestone built on the prior one. We started with AI readiness and a leadership problem statement. Then we developed a value hypothesis, implementation blueprint, responsible AI governance plan, change and adoption plan, cross-functional operating model, and final impact measurement plan.

For my portfolio, I focused on CoStar Group and designed an AI-assisted workflow for multifamily sales comp verification.

CoStar’s data business depends on trust. Customers do not buy sales comps because they are interesting. They buy them because those comps influence pricing, valuation, lending, investment analysis, and market confidence. If the data is wrong, stale, incomplete, or poorly explained, the customer problem is real.

My proposed AI initiative was not about replacing researchers. It was about helping researchers identify questionable multifamily sales comps earlier, review source conflicts, prioritize risky records, document decisions, and prevent material errors from reaching customer-facing products.

The three pillars of the project were accuracy, timeliness, and comprehensiveness.

Accuracy means fewer wrong prices, incorrect transaction classifications, missing context, or misleading comps. Timeliness means questionable records are reviewed faster and cleaner data reaches customers sooner. Comprehensiveness means the process does not only focus on the biggest or most obvious deals. It applies across the pilot markets so CoStar can improve the overall quality of its multifamily comp data.

My pilot focused on three Florida markets: Miami, Tampa/St. Pete/Sarasota, and Orlando. The AI would flag questionable comps, provide a confidence score, show why the comp deserves review, and point the researcher toward the source trail. The researcher would still make the decision: approve, correct, reject, pause, or escalate.

That human decision point was essential. The AI score is not the truth. It is a signal. A researcher still has to apply judgment.

What I Learned About Strategy
One of the biggest things I learned is that AI strategy has to be specific. “We should use AI” is not a strategy. “We should use AI to improve a defined workflow, for a defined user, with defined risks, measures, and decision rights” is much closer.

Bouquet, Wright, and Nolan (2026) argued that organizations need to match AI strategy to organizational reality. That was a helpful way to think about the work. AI strategy should fit the company’s actual business model, data quality, culture, systems, talent, and risk tolerance. Otherwise, the strategy may look great on paper but fail in the real world.

For CoStar, the reality is that the company’s premium depends on trusted data. Competitors can sell “good enough” alternatives at a discount. That means CoStar has to prove that its data is materially better. AI-assisted comp verification makes sense only if it strengthens that proof.

That led to one of my favorite lines from the final portfolio:

“A faster bad comp is not innovation. It is bad data wearing a tuxedo.”

That line is funny, but the point is serious. Speed without trust is not leadership. If AI simply moves questionable data through the system faster, it weakens the business instead of strengthening it.

What I Learned About Execution
The course also changed how I think about execution. A good AI idea can fail if the operating model is weak.

Euchner and Iansiti (2020), along with Iansiti and Lakhani (2020), helped frame AI as something that changes operating models, not just individual tasks. AI affects how information flows, how decisions are made, how teams coordinate, and how companies scale judgment. That means leaders have to design the operating model around the AI use case.

For my project, that meant defining who owns what. The Senior Research Director for Multifamily owns the pilot. Pilot research managers own day-to-day adoption and coaching. Researchers own source review and judgment. The AI/data team owns model performance. Product owns workflow usability. Legal/compliance owns responsible AI and external reliance concerns. Security owns data access and monitoring. Sales and Customer Success provide evidence over time about renewal defense, discount pressure, and customer objections.

This was another major lesson: when everyone is accountable, no one is accountable.

In normal business life, I think about it like sending an email. If I send one email to a large group and do not say who owns the next step, human nature takes over. People assume someone else will handle it. AI work has the same problem. The more cross-functional the work becomes, the more important it is to name one accountable owner for each major decision.

What I Learned About Governance
Responsible AI governance became one of the most important parts of my final portfolio.

The main risk in my project was not that AI would publish sales comps by itself. The risk was that AI would influence researcher judgment in ways that weaken accountability. A confidence score can look more authoritative than it really is. If researchers approve too quickly, AI becomes a shortcut. If the model flags too much, researchers may ignore it. If overrides are poorly documented, CoStar cannot explain why a comp was approved, corrected, rejected, or held back.

That is where governance has to become operational. In my project, manager review would be required when AI confidence falls below 80%, when sources conflict, when a comp is more than two standard deviations outside recent comparable sales, or when a transaction could materially affect customer-facing analytics. Those are not vague principles. They are workflow rules.

The course helped me understand that governance does not need to be heavy to be effective. In fact, a giant AI ethics board would probably be too much for a narrow pilot. A smaller governance group with clear decision rights is better. The goal is not bureaucracy. The goal is accountability.

What I Learned About Measurement
The final part of the course focused on impact measurement. This was critical because AI projects can create a lot of activity without creating much value.

Nieto-Rodriguez’s Benefits Card concept helped frame the idea that leaders should define benefits clearly and then measure whether those benefits are showing up. The course also included material on moving from AI promises to measurable outcomes. That is where many AI initiatives struggle. They measure tool usage, demo excitement, or productivity claims, but not whether the business actually improved.
For my final portfolio, I built a measurement plan around quality, adoption, risk, and financial logic. The pilot should not be judged by whether researchers used the AI tool. It should be judged by whether post-publication corrections decline, customer-reported comp issues fall, source reviews are documented, manager escalations happen when required, and the workflow produces better evidence for renewal and price-defense conversations.

The financial logic was also important. My project was not a headcount-reduction plan. That was not the point. The value came from trust-protected revenue. Better data quality should improve product stickiness, renewal confidence, lower discount pressure, and expansion support over time.

The plan included stop, pivot, and scale criteria. That was one of the most practical leadership lessons in the course. Before starting an AI initiative, leaders should define what success looks like, what warning signs require adjustment, and what failure would look like. Otherwise, companies may keep funding AI activity just because stopping would be embarrassing.

My Biggest Takeaways​
My biggest takeaway from AIN 712 is that AI leadership requires balance.

Leaders need enough optimism to see where AI can create value, but enough discipline to avoid chasing hype. They need enough technical literacy to ask intelligent questions, but they do not need to pretend to be engineers. They need to move fast enough to compete, but not so fast that they damage trust. They need to empower teams to experiment, but also define clear accountability.

The class also reinforced that AI is not separate from leadership fundamentals. It still comes down to strategy, execution, trust, communication, incentives, governance, and measurement. AI changes the tools, but it does not eliminate the need for judgment.
By the end of the course, my view of AI leadership became clearer. The winning organizations will not simply be the ones that adopt AI fastest. They will be the ones that know where to use it, how to govern it, how to lead people through the change, and how to measure whether it actually made the business better.

That is the leadership lesson I will carry forward:
AI should not be adopted because it is impressive. It should be adopted because it improves the business, strengthens decision-making, and earns trust.
​


Required Reading: