Freedom Within a Framework: Empowering Builders and Protecting Orgs

The tension between empowering builders and protecting the organization isn't new, but AI has made it more urgent. Organizations should enable the people closest to the work to innovate, while providing the governance needed to prevent shadow AI, security risks, and fragmented solutions.

The goal isn't to choose between innovation and control—it's to create clear guardrails that let builders move quickly while technology leaders provide the standards, security, and oversight needed to scale the best ideas safely.

Writing in The Wall Street Journal, technology researcher Joe Peppard argued that technology has become so central to business performance that technology knowledge and decision-making need to move closer to the work. The point for this guide is not that IT matters less. It is that IT matters more. When technology becomes part of how every function operates, IT leadership has to evolve from a centralized request queue into a strategic operating model for standards, security, architecture, enablement, and business partnership.

The phrase that matters comes from an energy-company executive Peppard interviewed: “freedom within a framework.”

Give builders room to solve real problems: approved tools, sandboxes, data rules, security standards, architectural guidance, and clear escalation paths. Let them build where the work is close, the risk is bounded, and the learning is valuable. Speed from the AI era makes the builder more valuable, and the framework more important. Download our latest eBook for the full guide.

A Framework Before You Build

Most real estate organizations are making the build vs. buy decision by feel, or sometimes simply to check a box (“we use AI”). Instead, ask yourself the following questions:

1. Is this problem the right place to put internal energy and investment?
2. If we build it, who maintains it — and what happens when that person leaves?
3. Does solving this problem here solve it for everyone, or just for one team?
4. Is there another solution that creates more value across the organization?
5. What are the risks if the tool fails, and who is responsible for managing them?

Sometimes the answer is yes, clearly and obviously. Internal builders are often the best people to solve narrow, high-specificity problems that vendors will never prioritize because the market for that exact problem is one organization.

Sometimes the honest answer is that a vendor has already solved it, or that the problem is significant enough that it deserves more comprehensive resources.

What to Watch When You Build

Most demos prove capability. Production tests accountability.

You build a proof of concept in a weekend. It handles 80% of cases beautifully. Leadership is impressed. You get the green light. What you demonstrated is that the model reasons well when the answer is in the room. What you did not demonstrate is whether your real problem is that kind of problem.

That hidden work often starts as review and exception management. There are workflows where the right answer is not contained in the data in front of you. It lives in organizational memory, years of accumulated judgment, exceptions, precedents, and the gap between how the business works on paper and how it works in practice.

A transaction may match the usual pattern, but this quarter the business restructured and the normal treatment is now wrong unless you know why the change happened. A multifamily investor may ask about per unit rehab cost. A general model might interpret that as unit-level economics: appliances, fixtures, finishes. The investor may mean per door cost across the entire project, the standard way the industry aggregates rehab budgets. Same words. Different meaning. A purpose-built vertical system is more likely to know the difference because the domain knowledge is baked into the product.

In CRE, accuracy is not only pulling the right number. It is pulling the right number under the right definition for the right decision.

Every Internal Build Needs an Exit Plan

The initial build is the easy part. But when you update a single instruction inside an AI agent, you break everything the agent has learned to do correctly.

The fix for one edge case becomes the source of a new failure somewhere else. That means any serious internal build requires backtesting: a process of running proposed changes against the full archive of historical cases to verify that the new behavior works without degrading the old. Building and maintaining a backtesting infrastructure is its own engineering project, invisible to the people using the tool, requiring ongoing attention from people who understand both the underlying models and the business logic the models are supposed to apply.

Then there is model deprecation. When a model provider updates or discontinues a model version, the tools built on top of it do not receive a graceful transition. They simply start behaving differently—or stop working.

In organizations where an internal tool is running quietly in the background, trusted because it has always worked, the change may go undetected until it has already affected outputs that people are depending on.

These are not hypothetical risks. They are the predictable lifecycle of any AI-powered internal build, and they require someone to own them, continuously, for as long as the tool is in use.

That is not a technology failure. It is an organizational one.

A healthy build program should include sunset rules.

Before a tool becomes widely used, answer: Who owns this tool? Who reviews it? How often is it tested? What would cause us to shut it down? What happens when the builder leaves? Where is documentation stored? How do users know whether it is approved? Is there a vendor or enterprise platform that should replace it if usage grows?

Every internal build needs an owner, and every owner needs an exit plan. Internal tools often survive too long because nobody decides when they should die.

Read "Your Builders Are Already Building: A CRE Leader's Guide to Build vs. Buy in the AI Era" for a practical framework on when to build the tools your business needs, when to buy them, and how to govern both.