This is a clip/paste from an email I just wrote, but if you're thinking about a global IBIS system, it might be a perspective you haven't considered.
Today's IBIS systems require a moderator to organize a map. They assume that the unit of work is creating a map or sections of a map. In a massive IBIS system, the unit of work can be a single node.
The sheer size of the group creates different opportunities for work distribution and different methods for controlling map organization. Think social generative programming.  In a massive generative system, users don't have to worry about creating well-formed maps, they can just worry about creating a single node. Instead of worrying about how moderators organize the maps, (Which is harder to scale), I'm more concerned with building an interface that leverages social norms and behaviors to produce well-structured IBIS maps from many uncoordinated asynchronous actions.
Consider also that massive systems include groups of people that don't exist reliably in business teams. Let's say that 1% of users create nodes, and 5% of users critique the nodes that others have created.  What sort of system will encourage 1% of users to post anything, even badly formatted single nodes, then get the 5% of critiquers to refine it over the following month?
So... in thinking about scaling the problem, I'm not thinking of scaling using the same kind of top-down organization that IBIS currently relies on. I'm thinking "How can we leverage individual and group behaviors to stimulate single node creation, iterated node refinement, and self-organizing maps that minimize the need for moderators?" That approach makes user interface design much more difficult (i.e., deceptively simple). However, if it's done correctly, scaling will be a beautiful thing to watch. And that's why I'm still working on the mockups right now. ;)
 Mitch Resnick's "Turtles, Termites, and Traffic Jams" http://books.google.com/books?id=K8P1rX8T4kYC
or see the book "Groundswell"