Designing AI Governance for Multifamily: An FAQ Grounded in NIST AI RMF and the RETTC Framework
If your portfolio is putting AI to work in leasing, screening, revenue management, maintenance, or resident engagement, the question is no longer whether you need AI governance. It is what your governance structure looks like, who sits on it, and how it makes decisions.
In This Article
Artificial intelligence is embedded across multifamily operations. Leasing fraud detection, predictive maintenance, revenue optimization, resident screening, marketing personalization, and affordability modeling all now involve AI systems making or shaping decisions that affect residents' access to housing, the price they pay, and the service they receive.
That is not a future scenario. That is right now, in your portfolio, whether or not you built the tools yourself.
Here is what makes this moment interesting. The industry is not short on AI tools. It is short on people who know how to evaluate, review, and govern them. And the operators building that muscle now are the ones who will move fastest with confidence, while others are still guessing.
18%
of organizations have an enterprise-wide council or board with authority over responsible AI governance, according to McKinsey's 2024 State of AI survey.
Source: McKinsey & Company, The State of AI in Early 2024
That number is not a failure. It is a snapshot of an early moment. It also frames the opportunity clearly. The organizations that put a structured AI governance body in place now are the same organizations that will be able to say yes to new AI capabilities faster, because they have a way to evaluate them responsibly.
This article walks through how to design that governance body for multifamily, grounded in two frameworks that already exist: the NIST AI Risk Management Framework and the RETTC AI Governance Framework for rental housing. Both are real. Both are public. Both are built to be used together.
Why AI Governance Councils Matter in Multifamily
Most multifamily organizations already have governance structures. Audit committees. Risk committees. Legal review workflows. Data privacy protocols. An AI governance council does not replace any of that. It sits at the intersection of technology, operations, legal compliance, and resident-centered ethics, with one job: make sure decisions about AI systems are not made in isolation.
Here is why that matters specifically in rental housing.
When an AI system helps decide whether an applicant gets a lease, how much rent a resident pays, or which maintenance requests get prioritized, the housing provider is legally and reputationally responsible for that decision. Not the vendor. Not the algorithm. You.
Grant Thornton's published analysis of AI in multifamily makes this point directly: vendors will drive most of the AI adoption in this sector, but regulatory responsibility and accountability remain with the housing provider. That means clear oversight has to sit inside the operating company, not inside the vendor's contract. An AI council is the structure through which that oversight gets consistently applied, including vetting vendor claims, requiring specific contractual protections, and monitoring the impact of vendor-provided AI over time.
Governance is not the thing that slows you down. It is the thing that lets you move fast with confidence. The council exists so that when the next AI capability shows up, you already know how to evaluate it, approve it, and monitor it, instead of stalling every conversation with the same unresolved risk questions.
The Two Frameworks That Shape Everything
You do not have to invent AI governance from scratch. Two frameworks already do most of the structural work for you.
NIST AI RMF
The AI Risk Management Framework from the U.S. National Institute of Standards and Technology. It is voluntary, cross-industry, and organizes AI risk management around four core functions: Govern, Map, Measure, and Manage. These functions are iterative, not linear. They apply throughout the lifecycle of every AI system.
RETTC AI Governance Framework
The Real Estate Technology and Transformation Center's framework is built specifically for rental housing providers and their technology partners. It is organized around eight principles: an organizational philosophy on AI use and oversight, fairness and consumer protection, transparency and explainability, privacy and data integrity, outcome-based accountability with human involvement, positive renter experiences and outcomes, innovation with responsibility, and third-party partner accountability. RETTC's framework is designed to align with NIST AI RMF, so the two are meant to work together.
How the four NIST functions map to your council's work
Now overlay RETTC's eight principles on top of those functions. Every decision your council makes runs through these principles. They are not slogans. They translate into specific questions your council asks about every AI system in your portfolio.
The eight RETTC principles, translated into council questions
Structuring Your AI Council
An AI council is a cross-functional body. Not a subcommittee of IT. Not an offshoot of legal. A dedicated group with representatives from every function the AI touches, and enough authority to make binding decisions.
One published example: OneTrust, a governance software company, has described its internal AI Governance Committee as including representatives from Legal, Ethics and Compliance, Privacy, Information Security and Architecture, Research and Development, and Product Management. Smaller working groups handle day-to-day reviews of individual use cases. An executive-level committee meets quarterly to review strategy, policy, and performance.
That specific structure is one company's approach, not a universal template. But the underlying logic transfers to multifamily. An analogous structure for a rental housing operator might include senior representatives from property operations, legal and compliance, IT and data, resident services, marketing, and vendor management, with working groups reviewing specific applications like leasing automation, revenue optimization, or resident-facing chatbots.
The key is that the council has to be embedded in your operating structure. It cannot be a purely advisory body with no connection to decision-making. It needs defined decision rights, clear escalation paths, and integration with your change management process. Grant Thornton's multifamily analysis makes this point explicitly: AI success requires clear ownership and an organizational structure that can support process redesign and adoption across the portfolio.
How Big Should Your AI Council Be?
Here is where a lot of AI governance content overreaches. You will see specific numeric benchmarks quoted in articles and blog posts, like "the average AI council has X members" or "councils with Y members reduce time to decision by Z percent."
Be careful with those. NIST AI RMF does not prescribe a specific council size. Neither does RETTC's framework. Any "average size" number you see should be traced back to its primary source before you use it to defend your own council design.
What both frameworks do prescribe is the shape of the group. NIST AI RMF is explicit that decision-making related to mapping, measuring, and managing AI risks should be informed by diverse and multidisciplinary teams. It calls out diversity of demographics, disciplines, experience, expertise, and background as directly connected to open sharing of ideas and identification of emergent risks. RETTC's principle on outcome-based accountability and human involvement reinforces this: your council needs voices that can speak to how residents and frontline team members experience the systems your council is reviewing, and someone accountable for the review process itself.
That guidance points toward calibration questions, not a headcount target.
Questions to size your council
If your organization is smaller and cannot spare a large group, a lean council of a few core members supplemented by working groups and external advisors is a reasonable starting point. If your organization is larger and has more AI touchpoints, a fuller cross-section is worth the coordination cost. Document your reasoning in the council charter either way, tied to NIST's diversity guidance and RETTC's principles on human involvement and positive renter experience.
Functions and Disciplines Your Council Should Cover
The following functional areas together cover the risk landscape your council needs to see. This is not a required roster. It is a checklist to test whether the perspectives you need in the room are actually present.
You already do this discipline. You quality-check your leasing calls. You audit your maintenance work orders. You review your marketing copy before it goes out. AI governance is the same discipline applied to your AI systems. Same instinct. Different subject.
Frequently Asked Questions
Do we need an AI council if we only use vendor AI tools?
Yes. Especially then. Regulatory responsibility does not move to the vendor when you buy their tool. Your council is the mechanism for verifying vendor claims, requiring specific contractual protections, and monitoring impact after the tool is in production. If most of your AI is vendor-supplied, the vendor-management role on your council is where the majority of the work will land.
How does an AI council relate to our existing risk or technology committee?
It can be a subcommittee of one of those, a standalone body, or a working group that reports up to your existing structure. Which model is right depends on how central AI is to your organization and how mature your existing governance is. Whatever the structure, the AI council needs a defined charter, defined decision rights, and defined escalation paths. Do not leave that unwritten.
What is the difference between an AI council and an AI ethics board?
Overlap, but different focus. An AI ethics board tends to be advisory and often includes external members. An AI governance council is operational. It reviews specific use cases, approves or blocks them, and owns the ongoing risk of the AI in your portfolio. You can have both. Many organizations combine the functions in early stages and separate them as AI adoption grows.
How often should the council meet?
NIST AI RMF does not specify. A common pattern is a working cadence, often monthly for the core group and quarterly for executive-level review, with issue-specific meetings called as new use cases come up for review. The specific schedule matters less than the principle: AI risk management is continuous and lifecycle-oriented, not a one-time approval at rollout.
What should the council actually review?
At minimum: every new AI system before it goes into production, every material change to an existing AI system, every new vendor introducing an AI component, and every incident where an AI system produced a concerning outcome. Set the intake threshold clearly so it is obvious what triggers review. Ambiguity here is where governance falls apart.
Do we need to document council decisions?
Yes. Documentation is central to RETTC's principle on outcome-based accountability and human involvement, and to the Govern function in NIST AI RMF. A decision record should include what was reviewed, what was decided, who decided it, what conditions or guardrails were attached, and what the monitoring plan is. If a regulator or plaintiff's attorney later asks how a specific AI system was reviewed, this record is your answer.
What if we do not have anyone internally with AI expertise?
Common in multifamily. You have two workable paths. First, build fluency deliberately across the team members you already have, so they can bring their functional expertise to AI questions with a working understanding of the technology. Second, supplement with external advisors for the technical depth you cannot yet cover internally. Both are appropriate. What is not appropriate is skipping the council because no one on your team has AI expertise yet.
How do we handle disagreement between council members?
Design for it. The council charter should define how decisions get made when there is not consensus, including how issues escalate to executive leadership. Disagreement is a feature, not a bug. It usually means the council is doing its job: surfacing tensions between competing legitimate concerns before they become external problems.
What This Means for Your Portfolio
Here is what the operators most prepared for the next AI regulatory wave are doing right now.
They are not waiting for a federal AI law to force them into governance. They are treating governance as the infrastructure that lets them say yes to new capabilities faster. When a new leasing AI tool shows up, they already have the intake process. When a vendor introduces an AI feature into an existing platform, they already have the review workflow. When a resident asks how a decision about them was made, they already have the answer.
They are also framing their council using structures that already exist, instead of reinventing them. NIST AI RMF gives them the four functions of Govern, Map, Measure, and Manage. RETTC gives them eight principles covering organizational philosophy, fairness and consumer protection, transparency, privacy, accountability with human involvement, positive renter outcomes, responsible innovation, and third-party partner accountability. The two frameworks overlap and reinforce each other, so operators using both do not have to choose.
The 18% figure from McKinsey is not a warning. It is a marker of where the industry sits at the front edge of formal AI governance. The organizations in that 18% are not necessarily larger or better resourced. They are the ones who decided the structure was worth building before they needed it.
You are not behind. You are right on time to make your next move a smart one.
Build fluency. Establish governance. Implement with confidence.
See the 2026 Tour
